• Free Key Generation Software
• Key Generator

• Jun 15, 2018  It is defined in 802.11i standard and has been adopted in home, small business (WPA2-Personal) and enterprises (WPA2-Enterprise) since 2004. The WPA2 implementation is based on the 4-way handshake.
• The PSK variants of WPA and WPA2 uses a 256-bit key derived from a password for authentication. The Enterprise variants of WPA and WPA2, also known as 802.1x uses a RADIUS server for authentication purposes. Authentication is achieved using variants of the EAP protocol. This is a more complex but more secure setup.
• Oct 23, 2010 Security How-To: WPA2-Enterprise on your home network. WPA Pre-Shared Keys (PSK) are breakable by brute force and depend largely on the strength of the key.

WPA encryption Key Generator

Create a WPA Key

This tool generate a WPA encryption key that you can use to secure your Wireless network. generate the WPA Encryption key, copy it and paste it into your wireless router's configuration panel. Restart your DSL modem/router.

Check the WEP Key generator

. WPA/WPA2-Enterprise mixed: Supports the transition from WPA-Enterprise to WPA2-Enterprise. You can have client devices that use either WPA-Enterprise or WPA2-Enterprise. Uses RADIUS servers for client authentication and dynamic WEP key generation for data encryption. Jan 09, 2018  What is WPA/WPA2 Enterprise & How it Works The world of technology and information. Wireless Authentication and Key Generation - Duration: 23:38. Brett Hill 51,138 views.

Wi-Fi Protected Access

If you choose WPA-Enterprise as the security mode, enter the following information:. Encryption: Choose either TKIP or AES as the encryption algorithm for data encryption. The default is TKIP. Key Renewal Timeout: Enter a value to set the interval at which the key is refreshed for clients associated to this SSID. The valid range is 0 to 4194303 seconds.

Wi-Fi Protected Access (WPA and WPA2) are systems to secure wireless (Wi-Fi) networks. They were created in response to several serious weaknesses researchers had found in the previous system, Wired Equivalent Privacy (WEP). WPA implements the majority of the IEEE802.11i standard, and was intended as an intermediate measure to take the place of WEP while 802.11i was prepared. WPA is designed to work with all wireless network interface cards, but not necessarily with first generation wireless access points. WPA2 implements the full standard, but will not work with some older network cards. Both provide good security, with two significant issues:

• either WPA or WPA2 must be enabled and chosen in preference to WEP. WEP is usually presented as the first security choice in most installation instructions.
• in the 'Personal' mode, the most likely choice for homes and small offices, a passphrase is required that, for full security, must be longer than the typical 6 to 8 character passwords users are taught to employ.

WPA is designed for use with an 802.1X authentication server, which distributes different keys to each user; however, it can also be used in a less secure 'pre-shared key' (PSK) mode, where every user is given the same passphrase. The Wi-Fi Alliance calls the pre-shared key version WPA-Personal or WPA2-Personal and the 802.1X authentication version WPA-Enterprise or WPA2-Enterprise. Generate pub priv keys for file encryption.

Source: Wikipedia

WEP Key Generator

Required software/hardware:

• FreeBSD 8.1 -- My favorite unix operating system and the OS used in the following post.
  
• FreeRADIUS -- Available through the FreeBSD ports tree at: /usr/ports/net/freeradius2/
• OpenSSL -- Available standard through the FreeBSD installation; however, ensure you are working with the most up-to-date release as OpenSSL tends to have some security issues.
• A router and/or access point that supports RADIUS servers and WPA2-Enterprise. DD-WRT is an excellent third-party firmware and will be used during this example.

The 12 step tutorial below represents all you need to get an operational instance of a WPA2-Enterprise protected network in your home or small business. The tutorial will walk you through certificate creation, deployment, configuration of FreeRADIUS, your Access Point/Router and your clients. I highly encourage you to read through the documentation provided by both OpenSSL and FreeRADIUS, especially around configuration files. The documentation will provide you greater insight into the software packages and is a life saver when you are trouble shooting. Always RTFM. Lastly, I would encourage you to read up on Public Key Infrastructure and digital certificates to ensure you understand exactly what is being done correctly here and the short cuts that have been taken.will walk you through certificate creation, deployment, configuration of FreeRADIUS, your Access Point/Router and your clients. I highly encourage you to read through the documentation provided by both OpenSSL and FreeRADIUS, especially around configuration files. The documentation will provide you greater insight into the software packages and is a life saver when you are trouble shooting. Always RTFM. Lastly, I would encourage you to read up on Public Key Infrastructure and digital certificates to ensure you understand exactly what is being done correctly here and the short cuts that have been taken.
Please use the index below to quickly jump around the document if you are looking for details on a specific step:

Step 1: Creating your Certificate Authority
Step 2: Generate new Certificate Authority Certificate
Step 3: Generate RADIUS Server certificate
Step 4: Generate Client Certificates
Step 5: Sign all Client Certificates
Step 6: Export Certificates for Windows & Mac
Step 7: Set up and Configure FreeRADIUS
Step 8: Test your Server Configuration
Step 9: Configure Wireless AP
Step 10: Deploying Certificates to Client Devices
Step 11: Setup Client Wireless (detailed directions for Windows XP SP3 Below)
Step 12: Configure FreeRADIUS to Start on Boot
Terminology
Summation
Update Log

Step 1: Creating your Certificate Authority

1.1 Create the directories needed by OpenSSL and FreeRADIUS:

• certstore/CA is our Certificate Authority's directory.
• certstore/CA/private is for our CA's private key
• certstore/certs directory is where our server certificates will be placed.
• certstore/newcerts directory is where OpenSSL puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (e.g. 100001.pem). OpenSSL needs this directory, so we create it.
• certstore/crl is where our certificate revocation list is placed.
• certstore/private is the directory where our private keys are placed.
• certstore/newcerts is the directory where we will place newly created certs and requests
• certstore/newcerts is the directory where we will place exported PCKS#12 formatted keys
• wireless/certs is our FreeRADIUS Certificate Store (keeping CA functionality and Server functionality separate)
• wireless/certs/clients is where we will keep our client certificates.
• wireless/certs/server is where server credentials will be kept.
  

Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose privileges a server runs. If anyone steals your private keys, then things get really bad.
1.2 Ensure directory is protected to root only access:
Permissions Explanation: 0700 = Read, write, execute owner (root) only
1.3 Create a database to keep track of each signed cert. The 'serial' file keeps track of signed certificates.

1.4 Edit openssl.cnf to customize to your needs

1.5 Create xpextensions file
The xpextensions file holds Extended Key Usage object identifier codes (OID) that are required to have OpenSSL generated certificates work with Microsoft products. Create the file and add the following content:

1.6: Ensure restrictive permissions of your config file:
Permissions Explanation: 0600 = read/write owner (root) only

Step 2: Generate new Certificate Authority Certificate

Generating your own Certificate Authority key pair will allow you to create and sign your own server and client certificates. As this is an internal network, we do not need to concern ourselves with having a certificate on a published trusted root authority list. Later in the deployment, we will use our own generated certificates and add them to a Trusted Root Authority certificate store for Windows clients.
Make sure these commands are executed in the /etc/certstore directory.
2.1 Generate the CA Certificate and Key pair
Note: The '-days' option is set to 3650, this means the CA cert will last for 10 years. This is because I am lazy and accept the security risk it introduces.
IMPORTANT: This where you must start keeping track of passwords for each of these files. I suggest creating a file on removable media. However, understand this introduces a security risk. I would also suggest using a random password generator that includes lower case, upper case, special characters, and numbers. Again, this is for your home network so you do not need 128-character passwords but they sure won't hurt. However, every time you need to sign a new certificate you will need this password.
2.2. Protect your newly created private key:

Permissions Explanation: 0400 = Read only by owner
2.3 Export your CA Key for deployment
These keys will be used for your client computers, they will need to have access to the CA key as they would a trusted CA like VeriSign, etc.


Step 3: Generate RADIUS Server certificate

3.1 Server signing request:

Free Key Generation Software

3.2 Sign Radius Server Certificate

Enter password. Confirm signing action.
3.3 Copy server key pair and CA key to /etc/wireless/certs/server


Step 4: Generate Client Certificates

This is an important step. Take an inventory of the devices that will be connecting through your wireless network. Ensure each device under your control has a unique certificate. I also make utility certificates for future use and a few guest certificates. For example:

• XPLaptop1
• XPLaptop2
• XPLaptop3
• XPLaptop4
• XPLaptop5
• Android1
• Android2
• AppleIOS1
• AppleIOS2
• GuestKey1
• GuestKey2
• GuestKeyOSX1

I invest the time to make these keys upfront and store them on a USB drive (kingston datatraveler, iron key, or some other encrypted USB drive) or CD-R for future use. It's easier to dig up the removable media than to remember exactly how to make the key if this isn't something you do regularly. Note: Ensure the Common Name field is changed from the default. Common Names should be unique to the specific key, i.e. XPLaptop1. Keep track of the common names used.
You will need to create a PEM password for each of these, choose something strong. Keep this PEM password on file as well.
UPDATE 2013-11-14: I have published a script that will greatly help with producing a massive amount of keys. Please see the post at http://www.privacywonk.net/2013/11/openssl-key-and-certificate-signing-requests-csr-generation-script.php

Step 5: Sign all client certificates

For each certificate generated you must sign it with the CA key.
5.1 For windows certificates use the following command:

5.2 For MAC OSX clients use the following command:

5.3 Copy client certificates (public key) to FreeRADIUS CertStore: /etc/wireless/certs/clients


Step 6: Export Certificates for Windows & Mac

It is recommended to use Public-Key Cryptography Standards (PKCS) 12 to export certificates for Microsoft compatibility. PKCS#12 defines a file format commonly used to store X.509 private keys with accompanying public key certificates, protected with a password-based symmetric key. When you are ready to move these files to movable media, simply download the entire contents of /etc/certstore/export.

A note on export passwords. Ideally, you should allow each user to choose their password. However, that will generally allow individuals to choose horribly weak passwords, thus compromising the certificate and making it susceptible to brute force attacks. X.509 certificates combine public and private key pairs into one binary file, the export password will control the access to the private key area. Choose something random and strong, just as you did for the PEM password.

Step 7: Set up and Configure FreeRADIUS

7.1 -- Setup Diffie-Hellman parameters and random file

Command Output:
Generating DH parameters, 1024 bit long safe prime, generator 5
This is going to take a long time
.......+....+...........+....................................
...................+.......+........+.+.+.+......+.......+...
.................+...+.........+..................+....+.....
+....++*++*++*++*++*++* (and screen fulls more of this)
DH parameters appear to be ok.
Command Output:
2+0 records in
2+0 records out
1024 bytes transferred in 0.000078 secs (13134457 bytes/sec)

Permissions Explanation: We chown the dh file to ensure freeradius can access it for use in DH exchanges. We then chmod it so that write permissions are removed from any other users. o = others '-w' = remove write permissions.
The 'dh' file created by openssl is a Diffie-Hellman parameters file. It is used by FreeRADIUS for negotiating TLS session keys. The Random file created by the 'dd' program is used for random data in TLS operations.
7.2 Configure eap.conf

7.3 Configure Clients.conf

7.4 Configure radius.conf

Note: The directives for logging stripped names, good and bad passwords will produce verbose log files. These are useful for debugging purposes; however, the logs can give away critical information. Below is an example of a log file produced when all of these directives are turned on:

Tue Oct 26 21:53:47 2010 : Auth: Login OK: [YourCertsCommonName1/] (from client YourAP/Router port 60 cli 0088dbc207e6)
Wed Oct 27 05:09:30 2010 : Auth: Login OK: [YourCertsCommonName2/] (from client Your/Router port 42 cli 00516f9b3176)
Mon Oct 25 02:13:06 2010 : Auth: Login incorrect: [InvalidKeyCommonName/] (from client boomsquad port 46 cli f09defea03fa4)
Mon Oct 25 02:14:15 2010 : Error: TLS Alert read:fatal:unknown CA
Mon Oct 25 02:14:15 2010 : Error: TLS_accept:failed in SSLv3 read client certificate A
Mon Oct 25 02:14:15 2010 : Error: rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Mon Oct 25 02:14:15 2010 : Error: SSL: SSL_read failed inside of TLS (-1), TLS session fails.

7.5 Update /usr/local/etc/raddb/sites-available/default
This file controls the authentication, authorization, and accounting modules available to FreeRADIUS. We want to lock this down to EAP only.

7.6 Secure FreeRADIUS Configuration files and Certificates
We need to protect our configuration files and certstore from prying eyes..

Permissions Explanation: Directories must be 0700 (Read, write, execute owner only) to allow for execution by the FreeRADIUS server; however, as the configuration files and certificates are not changed by the server they can be locked down to 0400 (read only).

Step 8: Test your Server Configuration

8.1 Test your config files
This will spit out a huge amount of debug text. You should not see any Warning or Error statements at all. Ideally, it will end with something along the lines of:

Listening on authentication address 10.0.1.75 port 1812
Listening on accounting address 10.0.1.75 port 1813
Listening on command file /var/run/radiusd/radiusd.sock
Ready to process requests.

Click here to see the full debug output of a successful startup.

Key Generator

If you see any errors, review your configuration files, RTFM, hit google, or leave me a comment and I will try to diagnose.
Once you have a successful startup and have figured out any potential configuration issues kill any running servers (Ctrl-C) and restart like so:

Move to a new terminal window run the following command:
This will allow you to watch the log in real time and also preserve a copy for later review. As we move toward setting up our access points and clients (supplicants) we can monitor if the AP is correctly passing traffic to the FreeRADIUS server, if the client (supplicant) is using the proper certificate, etc.
8.2 Testing FreeRADIUS
If you want to take the time to conduct a proper test, I would suggest the very detailed EAP-TLS testing methodology presented in the Free Software Magazine: HOWTO: Incremental Setup of FreeRADIUS Server for EAP Authentications. Specifically, 'Step 4. Full swing with EAP-TLS, EAP-TTLS and PEAP'.
It will will be very apparent if the configuration presented in this tutorial is working or not. However, good testing is always encouraged!

Step 9: Configure Wireless AP

Hopefully we have not wasted a lot of time only to find out your router does not support WPA2-Enterprise authentication. My Cisco/Linksys home router did not support it out of the box but DD-WRT, a third-party firmware, does.
Here is a screenshot. Setup is very simple:

Step 10: Deploying Certificates to Client Devices

Download the exported certificates to a USB drive or burn to a CD-R. If you have elected to setup random password in place of user supplied passwords, make sure you have a list you can copy and paste from while installing. This isn't great security but it makes deployment easier. Again, this is your home network not a classified network.
10.1 Install the Certificate Authority Certificate
Double click on the .DER file we made earlier (AwesomeCA.der). The following screen will show up:
Click the 'Install' Button.
This will take you to a screen that prompts for selection of a Certificate Store.
Select the second radio button 'Place all certificates in the following store' and click 'Browse.'
Select the 'Trusted Root Certification Authorities' store from the list. Click OK.
Click 'Next'
You will be prompted with a security warning. Click here for a screen shot (too big to display on webpage). Click Yes.
10.2 Install the Client Certificates
Double click on the .p12 file we made earlier.
Click Next.
A screen will verify the location of the key you want to import.
Click Next.
Enter the export password for the certificate. This will allow windows to successfully import the cert.
Click Next. Windows will inform you the certificate was successfully imported.
Step 11: Setup Client Wireless (detailed directions for Windows XP SP3 only below)
Setup a new Wireless network. Select WPA2 with AES Encryption
Click the Authentication Tab. Make sure to select 'Smart Card or other Certificate.' Click Properties.
Scroll to find and select the name of your Cert Authority in the list. Click OK.
iPhone Instructions (PDF)
MAC OSX Instructions (PDF)
Apple 802.1x Authentication Whitepaper (Enterprise guidance) (PDF)
Installing Certificates on Android 4.3 or higher

Step 12: Configure FreeRADIUS to Start on Boot

If your clients have successfully connected, kill whatever radius instances you may be running through the command line (for example, debugging server mention in step 8).
12.1 Add Radius to rc.conf to ensure FreeRADIUS starts on boot.

12.2 Start the server through the rc.d script.
Terminology
Authentication, Authorization, and Accounting (AAA) Protocol:
Authentication - Authentication refers to the process where an entity's identity is authenticated, typically by providing evidence that it holds a specific digital identity such as an identifier and the corresponding credentials. The digital certificates generated in this tutorial are a type of credential.
Authorization - Determines whether a particular entity is authorized to perform a given activity, typically logging on to an application or service
Accounting - tracking of the consumption of network resources by users.
Supplicant -- an entity at one end of a point-to-point LAN segment that seeks to be authenticated by an authenticator attached to the other end of that link. In practice, a supplicant is a software application installed on an
end-user's computer. The user invokes the supplicant and submits
credentials to connect the computer to a secure network. If the
authentication is successful, the authenticator typically allows the
computer to connect to the network
Authenticator -- an entity at one end of a point-to-point LAN segment that facilitates authentication of the entity attached to the other end of that link. In practice, the authenticator is usually a network switch or wireless access point/router that serves as the point of connection for computers joining the network.
Authentication Server -- servers that provide authentication services to users or other systems via networking. Remotely placed users and other servers authenticate to such a server, and receive cryptographic tickets. These tickets are then exchanged with one another to verify identity. In practice, and applicable to use in this post, FreeRADIUS.
Remote Authentication Dial In User Service (RADIUS) -- a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service.

Summation

While the content of this post will help you deploy some kick ass wireless security it is not a complete security solution. In fact, as I noted in the post, my way of handling keys and associated pass phrases introduces security risks. Protecting and managing your keys is critical to ensure the network remains secure.
Make sure you have locked down the FreeBSD computer that hosts the Certificate Authority and FreeRADIUS server.
If you have frequent guests using your network, I would suggest creating a segregated Virtual Wireless LAN for them to use instead giving them certificate-based access.
A note about maintaining a Certificate Authority. It's annoying. If you expect any a level of fluidity in your user base, employees leaving, frequent guests, etc. I would highly suggest investing the time into automating the certificate generation process. There are many tools out there that can assist in this. For example, TinyCA.
Lastly, I hope the post was useful and that you were able to successfully replicate a deployment of WPA2. I know there were a few unexplained areas in the post, if you have any questions please reach out.

Update Log

1. 2013-11-14 - Added Script for generating OpenSSL Certificates - http://www.privacywonk.net/2013/11/openssl-key-and-certificate-signing-requests-csr-generation-script.php
2. 2014-03-22 - Windows Phone will release the Enterprise Feature Pack sometime in early 2014. Once this is released, instructions for implementing EAP-TLS on the Windows Phone platform will be added to the post.
3. 2014-03-22 - Added iOS 7 deployment guides and Android 4.3 or higher