Алгоритм генерации at_mac для eap-aka ⇐ Python

[Anonymous]

Может быть, кто-нибудь может помочь с алгоритмом расчета параметров AT_MAC для аутентификации eap-aka?
Мне нужно ответить с 3 параметрами: at_rand, at_autn, at_mac.
Ясно, как генерировать at_rand и at_autn. . < /p>
У меня есть такие параметры ввода: < /p>

[*] 3gpp-sip-authorization < /li>

< li> Конфиденциальность-ключ
[*] целостность-клавиша
[*] Identity
3gpp-sip-authenticate
< /ul>
Когда я пытался вычислять это так (RFC 4187), он не работает: < /p>
10.15. AT_MAC

The AT_MAC attribute is used for EAP-AKA message authentication.
Section 9 specifies in which messages AT_MAC MUST be included.

The value field of the AT_MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
calculated over the whole EAP packet and concatenated with optional
message-specific data, with the exception that the value field of the
MAC attribute is set to zero when calculating the MAC. The EAP
packet includes the EAP header that begins with the Code field, the
EAP-AKA header that begins with the Subtype field, and all the
attributes, as specified in Section 8.1. The reserved bytes in
AT_MAC are set to zero when sending and ignored on reception. The
contents of the message-specific data that may be included in the MAC
calculation are specified separately for each EAP-AKA message in
Section 9.

The format of the AT_MAC attribute is shown below.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MAC | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The
HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
truncating the output to 16 bytes. Hence, the length of the MAC is
16 bytes.) The derivation of the authentication key (K_aut) used in
the calculation of the MAC is specified in Section 7.

When the AT_MAC attribute is included in an EAP-AKA message, the
recipient MUST process the AT_MAC attribute before looking at any
other attributes, except when processing EAP-Request/AKA-Challenge.
The processing of EAP-Request/AKA-Challenge is specified in

Arkko & Haverinen Informational [Page 63]
RFC 4187 EAP-AKA Authentication January 2006

Section 9.3. If the message authentication code is invalid, then the
recipient MUST ignore all other attributes in the message and operate
as specified in Section 6.3.

Здесь еще есть отсылка на секцию 7 где описывается алгоритм генерации ключа для расчета MAC

7. Key Generation

This section specifies how keying material is generated.

On EAP-AKA full authentication, a Master Key (MK) is derived from the
underlying AKA values (CK and IK keys), and the identity, as follows.

MK = SHA1(Identity|IK|CK)

In the formula above, the "|" character denotes concatenation.
Identity denotes the peer identity string without any terminating
null characters. It is the identity from the last AT_IDENTITY
attribute sent by the peer in this exchange, or, if AT_IDENTITY was

< /code>
Спецификация ясна, но результат отличается от рабочей системы. .

Подробнее здесь: https://stackoverflow.com/questions/794 ... or-eap-aka