Psk eap what to choose. EAP (Extensible Authentication Protocol)

7 EAP protocol

EAP (Extensible Authentication Protocol) is an extension to PPP. It contains a standard mechanism for supporting a number of authentication methods, including tokens, Kerberos, public keys, and S / Keys. This mechanism is fully supported by both Windows NT Dial-Up Servers and network clients Remote Access Dial-Up Networking Client. EAP is a critical component of a secure VPN, providing protection against violent attacks, dictionary guessing, and password guessing.

EAP extends the Windows NT Remote Access Service VPN capabilities by allowing authentication using third-party modules. The implementation of this protocol in the Windows NT environment was Microsoft's response to numerous requests from users who do not want to abandon familiar security hardware.

EAP was proposed by the Internet Support Task Force as an extension to PPP. It contains additional authentication mechanisms required to validate PPP connections. The main purpose of EAP is to dynamically connect authentication modules on both the client and server sides of such a connection. This protocol is very flexible, providing uniqueness and variability of authentication. A practical implementation of EAP is included in Microsoft Windows 2000.

7.1 Ensuring security at the transaction level

A very high level of VPN security is ensured through the use of microprocessor cards and authentication tokens. Microprocessor cards are small credit card sized devices with built-in CPUs and a small volume random access memory... This is usually where the user's identity (such as public key certificates), encryption keys, and account settings are entered. Some of the microprocessor cards also contain an encryption algorithm, thanks to which the crypto keys are never transmitted outside. In security systems for remote access, microprocessor cards are rarely used today, since only a few packages of this type support them. The situation should change from the advent of Windows 2000. This operating system will allow the use of such cards for a wide variety of authentication types, including RAS, L2TP and PPTP.

Authentication tokens are issued by various manufacturers, each of which puts its own work algorithm into them. But they are all nothing more than a hardware password generator. Some tokens are equipped with a miniature LCD display and a keypad, reminding appearance calculators. After the user enters his digital identification number, a secret digital code appears on the display screen, which acts as a password. Usually the secret code is unique and is never repeated even on this device... Authentication tokens are very useful for dial-up access (for example, when working with a remote access service), as well as for authenticating host computers. The network application of such tokens, as a rule, is based on client-server technologies (or built according to other schemes using passwords), therefore, it does not exclude the interception of transmitted secret information.

The synthetic protocol EAP-TLS (Extended Authentication Protocol-Transaction Layer Security) will support authentication tokens, as well as user certificates with a public key. It has already been submitted for consideration Target group technical support for the Internet as a draft specification for a high-security authentication method using public key certificates. In the EAP-TLS scheme, the client sends a user certificate to the remote access server, and in return receives a server certificate from it. The first of them ensures reliable user authentication on the server, and the second ensures that the client has made contact with exactly the server that he needs. Both parties to such an exchange rely on a chain of trusted certification bodies to validate the received data.

The user certificate can be stored directly on the client PC from which remote access is performed, or on an external microprocessor card. In both cases, the certificate can be used only after user identification, which is performed by exchanging one or another information (identification number, combination of username and password, etc.) between the user and the client PC. This approach fully complies with the principle of hardware and software protection recommended by most experts in the field of communication security.

EAP-TLS is essentially a form of EAP implemented in Windows 2000. Like MS-CHAP, it retrieves a crypto key that MPPE uses to encrypt all subsequent data.

7.2 RADIUS Authentication

RADIUS (Remote Authentication Dial-in User Service) is a central server with an authentication database and complements other request authentication protocols. This service is based on the UDP protocol, serving the PPP, PAP and CHAP protocols, as well as the function of logging into Unix systems and a number of other authentication mechanisms. In addition to its direct purpose, the RADIUS service also allows you to keep track of the VPN budget.

Having received from network service NAS authentication request to connect the user, the RADIUS server compares the received data with information from its database. There is also a central repository of connection settings for all registered users. If necessary, the server does not limit itself to a simple response to a request (YES / NO), but reports to the NAS a number of information regarding specific user... Specifically, it can specify the longest session time, a dedicated static IP address, and information to allow a callback to the user.

The RADIUS service can not only access its own database for autonomous processing of authentication requests, but also provide it to other database servers. In particular, it can be used by the general open server network connections or master domain controller. The latter is often located on the same computer as the RADIUS server, although this is not required. Among other things, a RADIUS server can act as a client proxy for a remote RADIUS server.

7.3 VPN Budgeting Using RADIUS Service

RADIUS allows centralized administration and budgeting of multiple tunnel servers. Most RADIUS servers can be configured to log authentication requests in a special account file. The specification provides a set of standard messages by which the NAS notifies the RADIUS server to send account user at the beginning of each call, at its end, or repeat it during the communication session at specified intervals. And third-party vendors offer a range of billing and auditing packages that generate various analytical documents based on RADIUS accounts.

7.4 EAP and RADIUS

To share EAP with a RADIUS server, adjustments must be made to both the NAS and RADIUS services. In the traditional authentication scheme, these services perform a single transaction, consisting of a request and a response to it. However, with EAP authentication, the NAS cannot independently collect the client information needed to authenticate to the RADIUS server. To solve this problem System Administrator can configure the NAS to send an identifier to the client by including it in the EAP message. The latter will respond with the username and domain information to the network authentication service. The NAS service includes them in the EAP-start request and, as such, forwards them to the RADIUS server. The further authentication process is performed as usual: the RADIUS service sends EAP messages to the client through the NAS service and responds to them until authentication gives a positive (or negative) result.

His name and password and gives permission to access the authorization server, which, in turn, gives the go-ahead to use the necessary network resources. However, this model does not answer the question of the reliability of information protection, since, on the one hand, the user cannot send his password to the identification server over the network, and on the other hand, permission to access services on the network ...

VPN is a Point-to-Point Tunnelling Protocol (PPTP). It was developed by 3Com and Microsoft to provide secure remote access to corporate networks over the Internet. PPTP leverages existing open TCP / IP standards and relies heavily on the legacy PPP point-to-point protocol. In practice, the PPP remains so ...

ANDREY PLATONOV

Building a secure wireless network: WPA-Enterprise, 802.1x EAP-TLS

Exists a good hundred insecurity clauses wireless networks... Moreover, many are completely identical and useless: they say that WEP is bad, that MAC addresses can be easily changed, and in the end they write: “There is only one way out and salvation. You need to use WPA. " And the point. This material contains exactly what you wanted to hear after the "dot" - a practical guide to organizing a well-secured wireless network.

Safe unsafe Wi-Fi

Today it becomes obvious that, despite all the problems associated with security, reliability and complexity of operation, wireless solutions of the 802.11a / b / g family have nevertheless become an integral part of the infrastructure of many corporate, home and even operator networks. This is partly because most of these problems are now a thing of the past in the current stage of Wi-Fi development. Wireless networks in all respects have become much smarter and faster: QoS appeared, smart antennas (MIMO technology), real speeds reached 40 Mbps (for example, SuperG technologies, SuperAG from Atheros). In addition, big changes have occurred in the set of technologies that ensure the security of wireless networks. Let's talk about this in more detail.

In the days when Wi-Fi was only for the elite, WEP encryption and MAC filters were used to protect wireless networks. All of this quickly became lacking, WEP was recognized as insecure due to the static nature of encryption keys and the lack of authentication mechanisms, MAC filters did not provide special security either. Development of a new IEEE standard 802.11i, which was designed to solve all the pressing security problems. Halfway to 802.11i, a set of technologies appeared under the general name WPA (Wi-Fi Protected Access) - part of the not yet ready 802.11i standard. WPA includes means for user authentication, encryption using dynamic WEP keys (TKIP / MIC). Then 802.11i was finally finished and WPA2 was born. To all of the above, support has been added for stronger encryption AES (Advanced Encryption Standard), which works in conjunction with the CCMP security protocol (Counter with Cipher Block Chaining Message Authentication Code Protocol - this is a more advanced analogue of TKIP in WPA). WPA2 gradually began to appear in new models of access points (for example, D-Link DWL-3200AP), but so far it is rather exotic. All products that support WPA2 are backward compatible with equipment that supports WPA.

Both WPA and WPA2 include advanced wireless access controls based on the IEEE 802.1x standard. The 802.1x architecture uses several required gates:

• Customer. The client is the Supplicant - the program on the client computer that controls the authentication process.
• Authenticator. It is an access point that acts as an intermediary between the client and the authentication server. The authenticator can also be a wired switch, since 802.1x is used on a variety of networks.
• Authentication Server - RADIUS server.

IEEE 802.1x allows for a variety of authentication methods and algorithms. This is possible thanks to the Extensible Authentication Protocol (EAP), in which the attributes corresponding to one or another authentication method are "nested". Therefore, there are many flavors of 802.1x EAP: EAP-MD5, EAP-PEAP, EAP-LEAP, EAP-SIM, etc. This article will describe the implementation of authentication in a wireless network based on digital certificates - 802.1x EAP-TLS. This method is most often used in corporate wireless networks and has a fairly high degree of security. In addition, EAP-TLS is sometimes one of the main methods of protection in the networks of wireless providers.

802.1x EAP-TLS Authentication

EAP-TLS is based on SSL v3.0, but unlike traditional authentication over SSL(for example, when establishing a secure http connection - HTTPS) in EAP-TLS, the client and the server are mutually authenticated. The client (supplicant) and the RADIUS server must support the EAP-TLS authentication method; the access point must support 802.1x / EAP authentication and does not need to know which authentication method is used in specific case... The figure below depicts the authentication process on a wireless network using EAP-TLS.

Here it is appropriate to end a small lyrical and theoretical digression, which is necessary in order to get a rough idea of ​​what lies in the depths of a secure wireless network. Further it will be offered practical implementation the concepts described above. A computer running FreeBSD 5.3 with FreeRADIUS package will be used as the RADIUS server. To organize the PKI (Public Key Infrastructure) infrastructure, the OpenSSL package will be used. The entire wireless network will be built on the basis of an inexpensive and reliable wireless equipment D-Link. It is assumed that Windows XP SP2 is installed on the client machines. in this operating system there is a built-in superlicant, and Microsoft's recent update adds support for WPA2.

Install and configure OpenSSL and FreeRADIUS

It is assumed that in FreeBSD system 5.3 one network card is installed, the collection of ports is updated, the Midnight Commander is present, and the computer itself is connected to the Internet. In the future, we will assume that the wireless network is deployed in a corporate network with a mask of 192.168.0.0/24.

To begin with, a few words about configuring a wireless network, and then we will give an example of configuring the D-Link DWL-2100AP to ensure interaction with a RADIUS server.

An intraoffice wireless network usually consists of several access points (all coverage is divided into small cells) that are connected to a wired switch. Often, switches with built-in Power support over Ethernet (802.3af) on ports (for example, D-Link DES-1316K). With their help, it is convenient to supply power to the access points scattered around the office. Nearby points are tuned to non-overlapping range channels so that they do not interfere with each other. In the 2.4 GHz band, in which 802.11b / g equipment operates, there are 3 non-overlapping channels for equipment with 11 channels, and 4 non-overlapping channels for equipment in which 13 channels can be selected (the broadband signal of the access point occupies 3 channels of the range). The D-Link DWL-2100AP and DWL-2700AP access points can be configured to any of 13 channels, in addition, you can enable the automatic tuning to an empty channel. So we will do it.

If the network has mobile subscribers that move across the entire coverage area, you can set all points with the same name of the wireless network - SSID, then the subscriber will automatically connect to a new point if the connection to the previous one is lost. At the same time, he will be re-authenticated, which, depending on the supplicant, will take from several seconds or more. This is how the simplest non-intelligent roaming within the network is realized. Another option: if each point has its own SSID, then you can configure several wireless profiles in the properties wireless connection and in the same place mark the option “connect to any available network". Thus, if the connection is lost, the client will connect to a new point.

We configure the DWL-2100AP to interact with RADIUS.

• We go to the web interface of the access point (how to do this, it is written in the instructions for the point), immediately change the default password on the TOOLS / ADMIN / tab.
• On the HOME / LAN tab, assign the IP address to the access point, which was set in clients.conf: 192.168.0.220.

• On the HOME / WIRELESS tab, we do everything as shown in fig. 3; in the "Radius Secret" field, specify the password that corresponds to this point in clients.conf (we specified "12345").

The rest of the access points are configured in the same way, only they will have different IP-addresses, channels (if they are set manually), as well as the value of the "Radius Secret" field.

We create certificates

First, a few general words about what PKI is. This is a kind of infrastructure, each subject of which has a unique digital certificate that proves his identity; among other things, a digital certificate contains a private key. Messages encoded with it can be decrypted by knowing the corresponding public key. Conversely, messages encrypted with a public key can only be decrypted with a private key. Each PKI subject has a public and private key.

The PKI subject can be either a user computer or a PDA, or any other element of the network infrastructure - a router, a web server, and even a RADIUS server, which is the case in our case. At the head of this whole system is the main authority CA (Certificate Autority), it is assumed that everyone trusts him and everyone knows him - he is engaged in signing certificates (certifying that the bearer of the certificate is really who he claims to be). He is assisted by special services for accepting requests for certificates and issuing them; the numbers of all issued and revoked certificates are kept in a special register. In reality, all this seemingly large farm fits on one computer, and one person can easily manage it.

To create certificates, we will use the scripts that come with FreeRADIUS.

• First, let's create our own CA - for this we will need to generate a digital signature, which will sign all the certificates issued by it, as well as the public key.
• Then we will create a server certificate, install it on RADIUS.
• Finally, we will generate certificates for installation on client computers.

Create the / usr / local / etc / raddb / CA directory, copy the CA.all file and the xpextensions file from the /usr/ports/net/freeradius/work/freeradius-1.0.2/scripts/ folder there. CA.all is an interactive script that generates CA, client and server certificates. Xpextensions is a file containing special Microsoft "Extended Key Usage" keys that are required for EAP-TLS to work with Windows systems.

Open the CA.all file:

• in line 1 we will correct the path - it should look like this:

SSL = / usr / local / openssl

• on line 32 we correct the path - it should look like this:

echo “newreq.pem” | /usr/local/openssl/ssl/misc/CA.pl -newca

Copy CA.all to the CA_users.all file. Then we open the last one and leave the text from lines 48 to 64, delete the remaining lines - the rest is the CA.all section, in which client certificates are generated. It will be used many times, so it is convenient to separate it into a separate script. Open CA.all, delete lines from 48 to 64 from it - everything that was selected in a separate script and save it.

Note: files CA.all and CA_users.all - contain the secret passphrase "whatever", which is used as additional remedy ensuring security, when issuing certificates and their revocation. A person who does not know this phrase will not be able to sign or revoke the certificate. In principle, except for the CA operator, no one else will need it. To improve security, you need to replace all words "whatever" in the CA.all and CA_users.all scripts with your password. It will also need to be entered in eap.conf in the "private_key_password = whatever" line. In what follows, I will assume that we have left the password “whatever” everywhere unchanged. We will introduce it by creating client and server certificates, as well as revoking them.

Create CA and server certificate

Launch CA.all. The first thing it generates interactively is the CA root certificate (cacert.pem), a pair of open private key(cakey.pem), the public key of the root certificate in PKCS # 12 format (root.der), then the server certificate (cert_srv.pem), which we will install on RADIUS. All of the listed files (and even some not listed) will appear in the CA folder.

Create a CA (it will be called "Administrator"):

Organizational Unit Name (eg, section): megacompany.central.office Common Name (eg, YOUR name): Administrator

Create a certificate for RADIUS:

Organization Name (eg, company): MegaCompany Co. Ltd. Organizational Unit Name (eg, section): RADIUS Common Name (eg, YOUR name): RADIUS Email Address: [email protected]

Copy the files /raddb/CA/cert_srv.pem and /raddb/CA/demoCA/cacert.pem to the / raddb / certs folder - installed the certificates on the RADIUS server.

We create client certificates

To generate client certificates, we use our CA_users.all script. For example, let's create a certificate for user user1:

• Open CA_users.all, replace all the words cert-clt. * In it with user1. * (This is necessary in order to distinguish by the file name which certificate is intended for which user, otherwise a certificate will be created with the same file name ( cert-clt. *). We will create several certificates at once for user1, user2,3,4,5). Alternatively, you can use the descriptive names of the files containing the certificate, for example, SergeyPetrov, IvanIvanov, etc.
• The password - "whatever" in lines 3, 4 is replaced with a real one, as shown in the listing:

CA_users.all file

1 | openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass: whatever -passout pass: whatever

2 | openssl ca -policy policy_anything -out newcert.pem -passin pass: whatever -key whatever -extensions xpclient_ext \

Extfile xpextensions -infiles newreq.pem

3 | openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out user1.p12 -clcerts -passin pass: whatever -passout pass: user1_password

4 | openssl pkcs12 -in user1.p12 -out user1.pem -passin pass: user1_password -passout pass: user1_password

5 | openssl x509 -inform PEM -outform DER -in user1.pem -out user1.der

For example, we enter "user1_password" - this password will be asked when installing the certificate on the user's computer, it must be remembered. This, as I said, is an additional means of authentication for actions related to issuing a certificate.

• We save and run the script, we get three files user1.der, user1.pem, user1.p12 - the latter is a certificate in PKСS # 12 format for installation on a Windows client.

Run the modified CA_users.all. Create a certificate for user1:

Country Name (2 letter code): RU

State or Province Name (full name): Moskow Locality Name (eg, city): Moskow Organization Name (eg, company): MegaCompany Co. Ltd. Common Name (eg, YOUR name): Andrey Ivanov Email Address: [email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password: whatever An optional company name: (press enter)

Now we generate a password for user user2:

• Open CA_users.all, replace user1. * In it with user2. *
• Replace the password "user1_password" with "user2_password" (do not forget to remember it so that you can install the certificate later).
• We save and run the script - we get the file user2.p12.

Create a certificate for user2:

Country Name (2 letter code): RU State or Province Name (full name): Moscow Locality Name (eg, city): Moscow Organization Name (eg, company): MegaCompany Co. Ltd. Organizational Unit Name (eg, section): IT Department Common Name (eg, YOUR name): Mikhail Ivanov Email Address: [email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password: whatever An optional company name:

We save each certificate on a separate floppy disk, write the installation password ("userX_password") on it, write the root.der public key on the same floppy disk (it is the same for everyone) and issue it to the user. The user installs the certificate on his computer (more on this later) and puts the floppy disk in the safe.

Installing certificates on the client computer

So, the user (let's say the one we named user1) received a floppy disk, the contents of which are two files root.der and user1.p12. Also written on the diskette is the password "user1_password".

Let's start by installing root.der

• double click on the root.der file;
• click "Install certificate";
• click "Next";
• select the option "Place all certificates in the following store", click "Browse" (Fig. 4);

• select "Trusted Root Certification Authorities", click "OK" (Fig. 5);

• click "Next", then "Finish";
• a security warning is issued: “It is not possible to verify that the certificate belongs to“ Administrator…. Install this certificate? " we press "Yes";
• the message "Import successfully completed." is displayed, click "OK" two times.

Install the user1.p12 user certificate.

• Double click on the user1.p12 file, click "Next" twice.

• Here you need to enter the password that we set for the user1 certificate. In our example, this is "user1_pass-word" (or whatever you come up with), it is conventionally written on a diskette with a certificate. Enter it and click "Next".
• Click "Next", then "Finish" - the message "Import successfully completed" is displayed, click "OK".

Note: all the certificates that we have installed can be viewed through the MMC using the Certificates -> Current User (Personal -> Certificates) snap-in.

Configuring wireless D-Link adapters DWL-G650 (DWL-G520 / DWL-G120) and supplicant

D-Link DWL-G650 is a CardBus adapter, DWL-G520 is a PCI adapter, and DWL-G120 is a USB adapter. They are configured in exactly the same way. Let's look at the procedure using the DWL-G650 as an example.

• We take the adapter out of the box, put it aside; install the drivers from the included disk. After installing the driver, we remove the native utility for configuring the adapter from startup, because we will use the wireless hardware configuration service built into Windows XP for these purposes. We insert the adapter into the computer.
• We click once with the left mouse button on the crossed-out wireless connection icon (in the system tray), then select the item "Change Extra options"(Fig. 7).

• Select the "Wireless Networks" tab, select our wireless network there (megacompany_DWL-2100AP), go to "Properties" (Fig. 8).

• On the "Connections" tab in the "Data encryption" drop-down menu, select the TKIP protocol. We move to the tab "Authentication" (Fig. 9).

• Here we leave everything unchanged, go to the "Properties" of the EAP (Fig. 10).

• We put the switches as shown in fig. 11, in the "Trusted Root Certification Authorities" window, select our CA - it will be called Administrator (if everything is done exactly as described in the "Creating certificates" section).

• Just in case, click "View certificate", and study who the certificate provider is. We make sure that this is our corporate CA "Administrator" that we created (Fig. 12).

• Click "OK", this is the setting network card and the supplicant is complete.

We check the work of WPA-Enterprise in our network

Now the long-awaited time has come to test all the settings in operation. Launch FreeRADIUS in debug mode with the "radiusd -X" command and see on the screen:

radius # radiusd –X

Starting - reading configuration files ... reread_config: reading radiusd.conf

At the end there are lines:

Listening on authentication 192.168.0.222:1812 Listening on authentication 192.168.0.222:1813 Listening on authentication 192.168.0.222:1814 Ready to process requests.

Well, or in the worst case, it is written why FreeRADIUS did not start - do not despair if this happens. You need to carefully study the error message and check all the settings.

Click on the wireless network connection icon, then on the wireless network named "mega-company_DWL-2100AP". Then we move our gaze to the monitor, on which radiusd is running and the process of successful authentication is displayed (we will not show the entire server output, because it is quite large, we will give only the initial and final lines).

Start of withdrawal:

rad_recv: Access-Request packet from host 192.168.0.220:1044, id = 0, length = 224 Message-Authenticator = 0x Service-Type = Framed-User User-Name = "Andrey Ivanov" Framed-MTU = 1488 Called-Station-Id = "00-11-95-8E-BD-30: megacompany_DWL-2100AP" Calling-Station-Id = "00-0D-88-88-D5-46" NAS-Identifier = "D-Link Access Point"

End of withdrawal:

User-Name = "Andrey Ivanov" Finished request 4 Going to the next request Waking up in 6 seconds ... Walking the entire request list --- Cleaning up request 0 ID 0 with timestamp 4294d303 Cleaning up request 1 ID 1 with timestamp 4294d303 Cleaning up request 2 ID 2 with timestamp 4294d303 Cleaning up request 3 ID 3 with timestamp 4294d303 Cleaning up request 4 ID 4 with timestamp 4294d303 Nothing to do. Sleeping until we see a request.

Authentication was successful, the computer obtains an IP address from the DHCP server and can now work on the wireless network. By the way, if several client certificates are installed on the computer (this also happens), then the superlicant will offer to choose which one to use for specific authentication.

Revoking certificates

It would seem that everything is already clear - a secure wireless network has already been built, but in fact there is one more important aspect that we will now consider. Suppose you want to deny access to the wireless network for one of the computers (for example, the personal laptop of one of the employees), on which we previously installed the certificate. The reasons can be the most commonplace - dismissal of an employee, reduction, etc. To solve this problem, you need to mark in the registry (/usr/local/etc/raddb/CA/demoCA/index.txt), which stores a list of all signed certificates, the certificate of the user we want to deny access to the network, as revoked. After that, you need to create (or update, if it already exists) a certificate revocation list (CRL - Certificate Revocation List). And then configure RADIUS so that when authenticating users, it will refer to this list and check if the presented client certificate is in it.

In our previous experiments, we created two certificates for user1 (Andrey Ivanov) and user2 (Mikhail Ivanov). For example, let's deny access to the wireless network for the latter. Let's go through the next three steps.

Step 1

We mark the user2 certificate in the registry as revoked: being in / usr / local / etc / raddb / CA we give the command:

radius # openssl ca -revoke user2.pem

943: error: 0E06D06C: configuration file routines: NCONF_get_string: no value: Revoking Certificate D734AD0E8047BD8F.

OpenSSL swears, but does what we want. During the execution of the command, you must enter a secret passphrase ("whatever"). In this case, in /raddb/CA/demoCA/index.txt, the certificate will be marked as revoked, which we can verify by looking at this file... The letter "R" appears next to the entry corresponding to the revoked certificate.

Step 2

Create a revocation list (CRL). If it already exists, it will be updated. Being in / usr / local / etc / raddb / CA, we give the command:

radius # openssl ca -gencrl -out ca.crl

Using configuration from /etc/ssl/openssl.cnf 963: error: 0E06D06C: configuration file routines: NCONF_get_string: no value: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c: 329: group = CA_default name = unique_subject Enter pass phrase for ./demoCA/private/cakey.pem: DEBUG: unique_subject = "yes"

Again, during the execution of the command, you must enter the secret password "whatever". As a result, the ca.crl file appears in the / raddb / CA / directory - this is the revocation list. Inside, it looks like an encryption, you can view it like this:

radius # openssl crl -in ca.crl -text –noout

Certificate Revocation List (CRL): Version 1 (0x0) Issuer: / C = RU / ST = Moskow / L = Moskow / O = MegaCompany Co. Ltd./OU=megacompany.central.office/CN=Administrator/ [email protected] Last Update: May 27 23:33:19 2005 GMT Next Update: Jun 26 23:33:19 2005 GMT Revoked Certificates: Serial Number: D734AD0E8047BD8D Revocation Date: May 27 23:13:16 2005 GMT Signature Algorithm: md5WithRSAEncryption D4: 22: d6: a3: b7: 70: 0e: 77: cd: d0: e3: 73: c6: 56: a7: 9d: b2: d5: 0a: e1: 23: ac: 29: 5f: 52: b0: 69: c8: 88: 2f: 98: 1c: d6: be: 23: b1: B9: ea: 5a: a7: 9b: fe: d3: f7: 2e: a9: a8: bc: 32: d5: e9: 64: 06: c4: 91: 53: 37: 97: fa: 32: 3e: df: 1a: 5b: e9: fd: 95: e0: 0d: 35: a7: ac: 11: c2: fe: 32: 4e: 1b: 29: c2: 1b: 21: f8: 99: cd: 4b: 9f: f5: 8a: 71: B8: c9: 02: df: 50: e6: c1: ef: 6b: e4: dc: f7: 68: da: ce: 8e: 1d: 60: 69: 48: ad:

We see in it one revoked certificate with the serial number D734AD0E8047BD8D (aka user2, aka Mikhail Ivanov).

Please note that an important property of the CRL is its expiration date. It must be updated no later than its expiration date (Update: Jun 26 23:33:19 2005 GMT). The CRL expiration date can be set in the openssl.cnf file (we had default_crl_days = 30).

Step 3

We connect the review list to FreeRADIUS:

• copy the file /raddb/CA/ca.crl to / raddb / certs / (over the old ca.crl, if it is there);
• go to / raddb / certs / and glue ca.crl to the cacert.pem file:

cat cacert.pem ca.crl> ca.pem

• make small changes to the section of the TLS file /raddb/eap.conf

# here we changed cacert.pem to ca.pem

CA_file = $ (raddbdir) /certs/ca.pem

CA_path = $ (raddbdir) / certs #add this line

check_crl = yes # and this line

Let's try to authenticate the computer with the user2 certificate on the network. Authentication fails, and user1 freely enters the wireless network, which was required to be proved.

Now the secure wireless network can be considered built.

EAP (Extensible Authentication Protocol)

EAP (Extensible Authentication Protocol) is an extension of the Point-to-Point Protocol (PPP); several authentication methods are based on it, providing for the exchange of credentials and other information of an arbitrary size. EAP was designed with the growing need for authentication tools using a wider range of security devices; it offers a standard architecture to support additional PPP authentication methods.

EAP can support multiple authentication algorithms - so-called EAP types, including access code generators, one-time passwords, public keys using smart cards, certificates, and more. EAP, combined with strong EAP types, is a key component of secure virtual private network (VPN) connection technology. Strong EAP types, such as certificate-based ones, provide better protection against brute force attacks or brute-force attacks than other password-based authentication protocols such as CHAP and MS-CHAP.

To find out if your organization is using any type of EAP, contact your network administrator.

On Windows XP there is support for two types of EAP:

• EAP-MD5 CHAP (analogous to CHAP authentication protocol);
• EAP-TLS (used for user certificate authentication).

EAP-TLS is a mutual authentication method in which both the client and server must provide proof of their identity. During an EAP-TLS session, the remote access client sends its user certificate and the remote access server sends its computer certificate. If at least one of these certificates is not transferred or is invalid, the connection is terminated.

Notes (edit)

• EAP-TLS authentication generates shared secret encryption keys for the Microsoft Point-to-Point Encryption (MPPE) algorithm.

If you find an error in the text, select it with the mouse and press the Ctrl + ENTER key combination, specify the correct text without an error.

When deploying wireless networks in a home or small office, the WPA security protocol option is usually used. shared keys- WPA-PSK (Pre Shared Key), also called WPA-Personal mode. It uses a static key similar to WEP. When using WPA-PSK in AP settings and profiles wireless connection Clients specify a password with a length of 8 to 63 printable ASCII characters. When connecting, the user will have to enter this password and, if the passwords match the entries in the database, he will receive permission to access the network.

In WPA-EAP (Extensible Authentication Protocol) mode, also called WPA-Enterprise mode, authentication requests are forwarded to an internal RADIUS server. The Network Policy Server (NPS) service provides RADUIS authentication to servers. The NPS server can pass authentication requests to a domain controller, allowing WPA-EAP secure wireless networks to authenticate domain controllers without users entering a key.

WPA-EAP provides very flexible authentication. For example, you can configure a user to connect to a secure WPA-Enterprise production network using a smart card. Since WPA-EAP does not use a static key, this security mode is easier to manage because there is no need to change the key if a hacker determines it. Multiple wireless access points can use one central server for authentication. In addition, this security mode is much more difficult to crack than WEP or WPA-PSK. wireless network encryption cryptographic

The encryption mechanisms used for WPA-EAP and WPA-PSK are identical. The only difference with WPA-PSK is that authentication is done using a password, not a user certificate.

Advantages and disadvantages

The advantages of WPA over WEP are:

• 1.Advanced RC4 data encryption scheme based on TKIP (Temporal Key Integrity Protocol).
• 2. Improved access control mechanisms - mandatory 802.1x authentication via EAP.
• 3. a model of centralized security management and the ability to integrate with existing corporate authentication schemes.
• 4.Possibility of easy installation for home users who can apply special treatment that automates WPA security configuration functions.

Among the disadvantages are:

• 1. WPA is less secure than WPA2.
• 2.the existence of vulnerabilities (described below),
• 3. This can also include the fact that in order to work with the WPA security protocol, it is necessary that all devices connected to the network have its support.

Disadvantages of WPA-PSK - a static key can be cracked using brute force techniques. Also, static keys are very difficult to manage in a production environment. If an individual computer configured with such a key is compromised, the key will need to be changed on each wireless access point.

Source: Bashmakov A.V., Lecture notes "Security of wireless networks"

Known vulnerabilities

Beck-Tevs method

On November 6, 2008, at the PacSec conference, two German students, Martin Beck from Dresden and Erik Tevs from Darmstadt, presented a way to crack the WPA TKIP key in 12-15 minutes.

TKIP had several features that made it at that time the most reliable protection... In particular, there was a sequence control in which the access point rejected all packets that arrived out of sequence. This protected against the so-called "replay attack", in which the transfer of the same data is repeated with malicious intent and not at all useful "attachment". TKIP also featured 64-bit integrity control of MIC packets, codenamed MICHAEL. TKIP, among other things, meant the transmission of each packet with a unique encryption key.

Since TKIP was created taking into account the possibility of a software upgrade of equipment that previously supported only WEP, the RC4 cipher was used in it, as well as 4 bytes for integrity control (ICV). The attack method proposed by Beck and Tevs in the report operates taking into account some of the assumptions given by the authors: the attacked network uses TKIP to encrypt traffic between the access point and clients; the network uses IPv4 for addressing with a pre-known address range like 192.168.0.X; long interval between key changes (3600 seconds in the example of the authors of the method); QoS (Quality of Service) is activated.

An attacker "listens" to traffic until it finds an ARP request or response (ARP protocol is used to match IP and MAC addresses in the network), such packets are easily calculated by their characteristic length. The hacker knows most of the contents of such a packet, except for the last byte of the address, 8 bytes of MICHAEL and 4 bytes of ICV checksum. MICHAEL and ICV together form the last 12 bytes. The hacker then uses (chopchop) methods to decrypt the remaining bytes. TKIP has two ways to combat these attacks:

• 1. If the client receives a packet with a bit ICV, it is considered a data transmission error and the packet is silently "discarded". If the ICV is OK, but the MIC verification fails, then the access point receives a corresponding notification, the so-called MIC failure report frame. If there are more than two such notifications within a minute, the connection is interrupted, and all keys are updated after a 60-second break.
• 2. If the packet is received correctly, then the counter is updated on the channel through which it was received. If incoming package received with the wrong sequence number, that is, out of order, such a packet is simply not accepted.

However, a workaround was found: the hacker simply needed to launch the attack on a different QoS channel than the one the packet passed through. If the last byte of the address was guessed incorrectly during the attack, the packet will simply be "discarded"; if it was guessed correctly, the client will send a MIC failure notification, but the counter will not work. A hacker needs to wait at least 60 seconds between sending packets in order not to provoke the 1st option of protection. A little over 12 minutes - and the attacking values ​​of MIC and ICV are at our disposal. It remains to guess only the IP addresses of the point and the client.

Further, a wide field for experiments opens. It is possible to redirect traffic using bogus ARP replies. If the client's firewall does not control outbound traffic, you can try to establish a two-way connection with the client, not receiving "responses" directly, but redirecting them over the Internet.

As countermeasures, Beck and Thevs proposed three options:

• 1. Set the key change interval to 120 seconds or less. During this period, the hacker will have time to decrypt only part of the ICV;
• 2. Disable sending the MIC failure notification;
• 3. Drop TKIP and go to AES-CCMP.

Ohigashi-Moriya Method

The method, developed by Hiroshima University employee Toshihiro Ohigashi and Kobe University professor Masakatu Morii, is based on Beck-Tews technology. This technology involves slightly modifying packets encrypted using the Temporal Key Integrity Protocol (TKIP) as part of the WPA security mechanism, and sending the modified packets back to the access point. The disadvantage of the Beck-Tewes method is that it takes 10 to 15 minutes to complete.

The method proposed by Ohigashi and Moriya, like the Beck-Tewes technology, uses the principle of a man-in-the-middle attack, which involves interfering with communication between users. The risk of detecting an attack with this approach is very high, so the ability to reduce the attack duration to 60 seconds is a huge advantage - at least for hackers.

It should be noted that WPA connections using the more secure AES key encryption standard, as well as WPA2 connections, are not susceptible to these attacks.

A little about WPA 2

On July 23, 2010, information about the Hole196 vulnerability in the WPA2 protocol was published. By exploiting this vulnerability, a malicious user logged into the network can decrypt other users' data using their private key. No key cracking or brute-force (brute-force) is required.

It would be more correct to say that the WPA2 security protocol was hacked, such an extensive vulnerability was found by experts in network security from AirTight Networks. They have proven that the WPA2 data protection protocol, which is currently the most widespread in WiFi networks, can be hacked in order to obtain any information from such a network. In addition, experts argue that the vulnerability can help hackers attack various resources using the capabilities of a compromised network.

The discovered vulnerability was found to be applicable to all wireless networks that are compliant with the IEEE802.11 Standard (Revision, 2007). The vulnerability also received its own name - Hole 196.

The vulnerability was found using a Man-in-the-middle attack. A person logged into such a network and using the exploit will be able to intercept and decrypt data transmitted within the network. In addition, when this "hole" is used, it becomes possible to spoof MAC addresses. Thus, information can be transferred to fake client systems, and this also allows the resources of the compromised network to be used to attack various web resources without much fear of being discovered.

Ways to Hack WPA Protected Wireless Networks

WPA-TKIP

Vulnerability in WPA-TKIP protocol discovered by researchers and aircrack-ng team members Martin Back and Eric Tuze.

As a result of exploiting the vulnerability, the master key cannot be recovered; you can only find out the key used to verify the integrity and the key stream. Based on this, without knowing the main key, it becomes possible to transmit packets to the network. Packets are received back in a similar way to easside-ng.

This vulnerability can be tested using the tkiptun-ng test tool added to aircrack-ng. It is known that to carry out an attack, you must change the MAC of your adapter to the MAC of the client being attacked. Also, the attacked access point must support QoS or WMM, use WPA + TKIP (not AES), and the time to change the temporary key must be more than 3600 seconds. If all this is present, then you can run: # tkiptun-ng -h -a -m 80 -n 100<интерфейс>.

After successful execution, you can get a key stream with which you can create packages and launch them on the network.

WPA2 is not affected by this vulnerability.

Classic WPA Hack. Interception of handshake.

The essence of the attack is to enumerate all possible combinations of a key before defining it. The method guarantees success, but if the key is long enough and not in dictionaries, then you can consider yourself protected from this attack. Thus, both WPA and WPA2 networks are cracked, but only in PSK mode.

WPA / WPA2 PSK encryptions are vulnerable to dictionary attacks. To carry out this attack, you need to get a 4-way WPA handshake between the wifi client and the access point (AP), as well as a dictionary containing the passphrase.

WPA / WPA2 PSK works as follows: it derives from a pre-session key called the Pairwise Transient Key (PTK). PTK, in turn, uses the Pre-Shared Key and five other parameters - SSID, Authenticator Nounce (ANounce), Supplicant Nounce (SNounce), Authenticator MAC-address and Suppliant MAC-address. -client). This key further uses encryption between the access point (AP) and the wifi client. An attacker who is listening to the broadcast at this moment in time can intercept all five parameters. The only thing the villain doesn't own is the Pre-Shared key. The Pre-Shared key is obtained (created) by using the WPA-PSK passphrase that the user sends along with the SSID. The combination of these two parameters is sent through the Password Based Key Derivation Function (PBKDF2), which outputs the 256-bit "new shared key.

In a typical / typical WPA / WPA2 PSK dictionary attack, an attacker will use the dictionary with the program (tool). The program will output a 256-bit "new Pre-Shared Key for each passphrase and will use it with the other parameters that were described in the creation of the PTK. The PTK will be used to check the Message Integrity Check (MIC) in one of the handshake packages. match, then the passphrase in the dictionary will be correct, otherwise vice versa (incorrect).

This attack is built into the aircrack-ng package. First, you need to catch the client's authentication in order to recover the primary key based on it. This is easiest to do by running # airodump-n g and waiting for authentication, or by running a deauthentication attack # aireplay-ng -0<количество деаутентификаций> ... After a while, airodump-ng will show that the authentication has been caught and written to the file. After that, you just need to run aircrack-ng<файл аутентификации> and wait.

You can speed up the process by using a large vocabulary with frequently used words. The use of specialized microcontrollers or video cards will also help. Without this, too many possible keys will take too long.

Quite long and unusual keys can be used to counter such an attack.

Wi-Fi Protected Setup

Wi-Fi Protected Setup (WPS) is a standard for semi-automatic creation of a wireless home network created by the Wi-Fi Alliance. Officially launched on January 8, 2007.

Most modern routers support the WPS mechanism. The purpose of the WPS protocol is to simplify the process of setting up a wireless network, which is why it was originally called Wi-Fi Simple Config. The protocol is intended to help users who do not have a broad knowledge of security in wireless networks, and as a result, have difficulties in making settings. WPS automatically identifies the network name and sets the encryption to protect against unauthorized network access, without the need to manually set all the parameters.

There are three options for using WPS:

• 1. Push-Button-Connect (PBC). The user presses a special button on the router and on the computer (software), thereby activating the setup process.
• 2. Entering the PIN in the web interface. The user enters the administrative interface of the router through a browser and enters an eight-digit PIN code written on the device's case, after which the configuration process takes place.
• 3. When connecting to the router, you can open a special WPS session, within which you can configure the router or get the existing settings if you enter the PIN code correctly. No authentication is required to open such a session. It turns out that the PIN is already potentially susceptible to a bruteforce attack.

Here the PIN is eight digits long - hence there are 10 ^ 8 (100,000,000) options to pick. But the fact is that the last digit of the PIN is a checksum, which is calculated based on the first seven digits. As a result, we already get 10 ^ 7 (10,000,000) options. In addition, the PIN code check is carried out in two stages - each part is checked separately. We get 10 ^ 4 (10,000) options for the first half and 10 ^ 3 (1,000) for the second. In total, there are only 11,000 options for a complete search. But here it is worth noting one important point- the possible speed of the search. It is limited by the speed of processing WPS requests by the router: some access points will return a result every second, others - every ten seconds.

Implementation of brute force can be done using the utility wpscrack, as well as using the utility Reaver... Reaver will be preferred due to its greater functionality and support for many more wireless adapters.

As with any attack on a wireless network, you need Linux. To use Reaver, you need to do the following:

• § find out the name wireless interface - $ iwconfig;
• § translate wireless adapter to monitoring mode - $ airmon-ng start ***(usually wlan0);
• § find out the MAC address of the access point (BSSID) with WPA / WPA2 encryption and PSK key authentication - $ airodump-ng ***(usually mon0);
• § make sure that WPS is activated on the outlet - $ ./wash -i mon0.

After that, you can proceed directly to brute force PIN "a. You must specify the name of the interface (previously transferred to monitoring mode) and the BSSID of the access point:

$ reaver -i mon0 -b 00: 21: 29: 74: 67: 50 -vv

The "-vv" switch enables extended program output so that you can make sure everything is working as expected. If the program consistently sends PINs to the access point, then everything is working well, and you just have to wait. The process can be delayed - approximately the time can vary from four to ten hours. As soon as it is found, the program will inform you about it and issue it. WPA-PSK, can be used immediately for connection.

It is also worth noting that there is a faster option. The fact is that some of the same router models usually have the same PIN. And, if the PIN of the model of the selected router is already known, then the hacking time is literally a few seconds.

There is only one way to defend against an attack - disable WPS in the router settings. True, this is not always possible. Or, to counteract brute-force as much as possible, you can block WPS indefinitely after several unsuccessful attempts to enter the PIN. Then the search can drag on for a very, very long time, depending on the set value of the blocking period.

A little about WPA / WPA2-Enterprise. Hacking MS-CHAPv2.

In Enterprise, MS-CHAPv2 is only one of the possible EAP methods. The popularity of MS-CHAPv2 is due to the fact that it is the easiest method to integrate with Microsoft products(IAS, AD, etc.).

MS-CHAPv2 is claimed to be cracked with 100% success rate. To do this, you need to intercept the exchange using the MS-CHAPv2 protocol, after which, using encryption vulnerabilities, you can calculate the user's credentials. MS-CHAPv2 is claimed to be used in VPN and WPA2-Enterprise systems. At the same time, both VPN and WPA2 are mentioned in the context of AAA servers (Authentication, Authorization, Accounting), which is quite logical, since it is there that the unencrypted MS-CHAP is caught. That is, if you intercept the MS-CHAPv2 exchange between the client and the AAA server, you can calculate the user's credentials.

But since interception of the MS-CHAPv2 session is no longer possible in the presence of a tunnel (first, you need to break the encryption of the tunnel), this method of cracking is valid only if you simulate an access point. Then you can safely get both the client and its MS-CHAPv2 session, provided that there are no certificates on the access point and certificate verification on clients is disabled.

Thus, for a well-built wireless network with WPA2-Enterprise based on PEAP / MS-CHAPv2, such an attack is not terrible. Unless, to wedge into the channel between the authenticator (access point, controller) and the AAA server, but this does not apply to WPA anymore.

The purpose of the Authentication and Key Agreement (AKA) procedure is to perform mutual authentication between the user terminal and the network, and to generate the security function key KSEAF (see Figure 7). The once generated KSEAF key can be used to form several security contexts, incl. for 3GPP and non-3GPP access.
Release 15 3GPP defines two mandatory authentication and key agreement procedures - EPS-AKA "and 5G-AKA, which will be discussed below.
Within both methods, the derivation function (KDF) is called, which, based on the control character string, converts the cryptographic key. The control character string may include the name of the serving subscriber of the guest network (Serving Network Name - SN-name). In particular, SN-name is used when calculating:
- security function key KSEAF;
- Authentication response (RES *, XRES *);
- intermediate keys CK 'and IK'.
The SN-name is constructed by combining a service code (service code = "5G") and an identifier of the visited network that authenticates the user (network identifier or SN Id). SN Id is calculated based on mobile code Country (MCC) and Mobile Network Code (MNC) - see Fig. 3.

Rice. 3 (network identifier or SN Id)

Using the name of the serving network (SN-name) allows you to unambiguously bind the results of the cryptographic algorithms to a specific guest network.

Initiating and Selecting an Authentication Method

In accordance with the operator's security policy, the SEAF functional module can initiate user terminal (UE) authentication in any procedure involving the establishment of a signaling connection with the UE, for example, when registering with the network (attach) or updating the tracking area (tracking area update). To "go on the air", the UE must use either the hidden SUCI (in the case of initial registration in the network) or 5G-GUTI (otherwise).
To authenticate the user terminal, SEAF uses a previously created and not yet used authentication vector, or sends an Authentication Initiation Request (5G-AIR) to the AUSF, setting SUCI as the user identifier (in the case of initial registration in the network), or SUPI (when receiving from the UE of a valid 5G-GUTI). The authentication request (5G-AIR), in addition to the user ID, must also include the type of access (3GPP or non-3GPP), as well as the serving network name (SN-name).
Next, the AUSF verifies the eligibility of using the serving network name (SN-name) and, upon successful verification, translates the received request into the unified database (UDM) block, where (if necessary) the user identifier retrieval functional module (SIDF) decrypts the hidden user identifier (SUCI) ), after which the authentication credential repository (ARPF) selects the appropriate authentication algorithm - 5G-AKA, or EAP-AKA ".

EAP-AKA Authentication Method "

The EAP-AKA authentication method "is further development EAP-AKA and introduces new function derivation linking cryptographic keys to the name of the access network. The EAP-AKA "method described in RFC 5448 is triggered by UDM / ARPF when it receives a user authentication request from the AUSF (Authentication Information Request - Auth Info-Req messages). Figure 4 shows a diagram that includes the steps listed below.

Rice. 4 (EPS-AKA Authentication Method)

1. The user credential repository and processing module (UDM / ARPF) generates an authentication vector including RAND, AUTN, XRES, CK, IK. To calculate the authentication vector, five one-way functions f1-f5 are used, implemented on the basis of the MILENAGE block cipher (in accordance with 3GPP TS 33.102 - see Fig. 5) with the AMF bit set to "1". When calculating f1-f5, a 128-bit operator-variant algorithm configuration field (OP) is used. OP allows you to make a unique (secret) implementation of the algorithm for each operator. The OP value (or OPc computed from OP and KI via the block cipher function) must be stored in the ARPF and on the user's USIM.

Rice. 5 (Authentication vector)

2. UDM / ARPF through the derivation function and using the serving network name (SN-name) calculates the "associated" values ​​CK ", IK" and transmits the vector (RAND, AUTN, XRES, CK ", IK") to the authentication server (AUSF) from which the request was received.
3. AUSF starts the cryptographic function PRF of the EAP-AKA method "described in RFC5448. The input parameters of the function are the keys CK" and IK ", as well as the name of the serving network (SN-name). The following fields are obtained at the output of the function:
- K_encr — key (128 bit) used to encrypt individual attributes of EAP-AKA messages "(in accordance with the operator's security policy);
- K_aut - key (256 bit) used to calculate the message integrity control codes EAP-AKA "(MAC - Message Authentication Code);
- K_re - key (256 bits) used for re-authentication;
- MSK (Master Session Key) - master key (512 bit);
- EMSK (Extended Master Session Key) - extended master key (512 bits).
4. The AUSF sends an EAP-Request / AKA "-Challenge" to the Security Anchor Function (SEAF), which is then transparently broadcast to the user terminal in the NAS message. The EAP-Request / AKA "-Challenge" contains the following attributes:
- AT_RAND (random number);
- AT_AUTN (authentication token);
- AT_KDF (identifier of the used derivation function, where 1 - corresponds to the use of the default derivation function);
- AT_KDF_INPUT (serving network name - SN-name);
- AT_MAC (Message Authentication Code).

- calculates the values ​​of XMAC, RES, CK "and IK";
- starts the cryptographic function PRF of the EAP-AKA algorithm "(similar to the function performed by the authentication server);
- checks the correctness of the message integrity control code (AT_MAC attribute);
- verifies that the AMF bit of the AT_AUTN attribute is set to "1";

- sends an EAP-Response / AKA "-Challenge" with AT_RES and AT_MAC attributes to the Security Anchor Function (SEAF), which is then transparently broadcast to the Authentication Server (AUSF).
6. AUSF verifies the correctness of the message integrity check code (AT_MAC attribute) and authenticates the user terminal by comparing the RES and XRES values ​​received from the UE and ARPF / UDM, respectively.
7. If successful, the AUSF sends an EAP-Success response to the UE via the Security Anchor Function (SEAF). If the operator's security policy implies the transmission of EAP-Success in encrypted form - "protected successful result indications", notification messages are exchanged first. Also (if necessary), through the SIDF function call, the hidden identifier (SUCI) decryption and 5G SUPI extraction are performed.
8. At the final step, ARPF / UDM generates an authentication function key KAUSF, which is used as the first 256 bits of the Extended Master Key (EMSK). Further, based on KAUSF, encryption and integrity control keys are calculated in accordance with the hierarchy of cryptographic keys shown in Fig. 7.

The 5G-AKA authentication method is a further development of the EPS-AKA described in 3GPP TS 33.401 and applied on 4G-LTE networks. The 5G-AKA method is launched by UDM / ARPF when it receives a user authentication request from AUSF (Authentication Information Request messages - Auth Info-Req). In Fig. 6 is a diagram that includes the following steps.

Rice. 6 (5G-AKA Authentication Method)

1. By analogy with the EAP-AKA algorithm "the module for repository and processing of user credentials (UDM / ARPF), based on the MILENAGE block cipher, generates an authentication vector that includes RAND, AUTN, XRES, CK, IK (the AMF bit must be set to unit).
2. UDM / ARPF through the derivation function and using the serving network name (SN-name) calculates:
- the associated value of the expected response XRES *,
- the value of the key of the authentication function KAUSF,
generates a vector "5G HE AV" (Home Environment Authentication Vector), including RAND, AUTN, XRES *, KAUSF and sends it to the authentication server (AUSF).
3. AUSF calculates:
- the HXRES * value, which is a hash truncated to 128 bits from the concatenation of the expected XRES * authentication response and a random number RAND: HXRES *  lower 128 bits from SHA-256;
- the value of the key of the security function KSEAF.
Next, the AUSF generates a 5G AV (5G Authentication Vector) including RAND, AUTN, HXRES *, KSEAF and sends it to the security anchor function (SEAF) via a 5G-AIA (Authentication Initiation Answer) message. In case the authentication request (5G-AIR) contained a hidden user identifier (SUCI), the AUSF, through the SIDF function call, receives the 5G SUPI and adds it to the 5G-AIA.
4. SEAF monitors the received vector lifetime timer and sends an Auth-Req message with the RAND and AUTN parameters turned on to the NAS user terminal.
5. User terminal:
- calculates RES, AUTN, CK, IK values ​​by calling the corresponding functions of the USIM module;
- performs network authentication by comparing the computed and received AUTN values;
- calculates the values ​​of the keys KAUSF and KSEAF;
- computes the associated RES * authentication response value;
- Sends an Auth-Resp message containing RES * to the Safety Anchor Function (SEAF).
6. SEAF calculates the hash HRES * (similar to AUSF) and authenticates the user terminal by comparing HRES * and HXRES *.
7. Upon successful authentication, SEAF sends to AUSF a 5G-AC (Authentication Confirmation) message containing incl. the RES * response value received from the UE. This step is optional and may not be used when registering a user on a home network.
8. AUSF checks the lifetime timer of the authentication vector, compares the calculated (XRES *) and received (RES *) responses, and then completes the authentication procedure.
3GPP recommends that only one vector be generated and used within one authentication procedure. This will allow each authentication procedure to be completed with a confirmation message.