MIKEY: Протокол управления ключами для мультимедийных сессий

the cryptographic protocol

Multimedia Internet KEYing (MIKEY) is a key management protocol that is intended for use with real time applications. It can specifically be used to set up encryption keys for multimedia sessions that are secured using SRTP, the security protocol commonly used for securing real time communications such as VoIP. MIKEY was first defined in Additional MIKEY modes have been defined in , , , and .

As described in RFC 3830, the MIKEY protocol is intended to provide end to end security between users to support a communication. To do this, it shares a session key, known as the Traffic Encryption Key (TEK), between the participants of a communication session. The MIKEY protocol may also authenticate the participants of the communication. MIKEY provides many methods to share the session key and authenticate participants.

MIKEY is used to perform key management for securing a multimedia communication protocol. As such, MIKEY exchanges generally occur within the signalling protocol which supports the communication. A common setup is for MIKEY to support Secure VoIP by providing the key management mechanism for the VoIP protocol (SRTP). Key management is performed by including MIKEY messages within the SDP content of SIP signalling messages.

MIKEY supports eight different methods to set up a common secret (to be used as e. g. a session key or a session KEK):
Pre Shared Key (MIKEY PSK): This is the most efficient way to handle the transport of the Common Secret, since only symmetric encryption is used and only a small amount of data has to be exchanged. However, an individual key has to be shared with every single peer, which leads to scalability problems for larger user groups. Public Key (MIKEY PK): The Common Secret is exchanged with the help of public key encryption. In larger systems, this requires a PKI to handle the secure distribution of public keys. Diffie–Hellman (MIKEY DH): A Diffie–Hellman key exchange is used to set up the Common Secret. This method has a higher resource consumption (both computation time and bandwidth) than the previous ones, but has the advantage of providing perfect forward secrecy. Also, it can be used without any PKI. DH HMAC (MIKEY DHHMAC) (HMAC Authenticated Diffie–Hellman): This is a light weight version of Diffie–Hellman MIKEY: instead of certificates and RSA signatures it uses HMAC to authenticate the two parts to one another. DH HMAC is defined in RFC 4650. RSA R (MIKEY RSA R) (Reverse RSA): The Common Secret is exchanged with the help of public key encryption in a way that doesn't require any PKI: the initiator sends its public RSA key to the responder, which responds by selecting the Common Secret and then send it back to the initiator encrypted with the initiator's public key. RSA R is defined in RFC 4738. TICKET (MIKEY TICKET): Ticket Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY). MIKEY TICKET is defined in RFC 6043. IBAKE (MIKEY IBAKE): Identity Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). MIKEY IBAKE is defined in RFC 6267. SAKKE (MIKEY SAKKE): Sakai Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). This is an Identity Based Authenticated Key Exchange method. MIKEY SAKKE is defined in RFC 6509.

The majority of MIKEY methods requires the initiator to send a message to participants (the I MESSAGE), and the receivers to respond with another message (the R MESSAGE). Once this exchange has completed, the session key can be generated by the participants. MIKEY SAKKE does not require an R MESSAGE.

MIKEY messages are made up of a number of payloads. Each payload describes the next payload in the MIKEY message. In this way the MIKEY protocol has shown it is flexible to being extended and adapted. The first payload is always the Common Header (HDR). This identifies the version of the MIKEY protocol, the method used (data type), whether a response is required and it identifies the cryptographic session that will be established via the exchange. Further payloads are defined by the MIKEY method in use. Frequently these will include information payloads such as:
A timestamp payload (T) this contains the time and hence helps protect against replay attacks. Identity Payloads (ID) this identifies the participants. This payload type can also contain certificates (CERT). This was extended in RFC 6043 to include the 'role' of the user as part of the ID (IDR). A RAND payload (RAND) this is random data used to salt the post exchange key derivation. Security Policies (SP) this contains a limited set of security policies to support the communication. Certificate Hash (CHASH) a hash indicating a certificate used for public key encryption. In addition to this, the MIKEY message will contain at least one payload which encapsulates key material. These include:
Key data transport (KEMAC) this encapsulating the key by encrypting it using a pre shared secret. This is extended by RFC 4650 to support authenticated Diffie–Hellman (DHHMAC). Diffie–Hellman (DH) this contains cryptographic information supporting the Diffie–Hellman protocol. Envelope Data (PKE) this encapsulates the key using public key encryption. This is extended by RFC 4738 and RFC 6267. Sakai Kasahara (SAKKE) this encapsulates the key using the identity based Sakai Kasahara protocol. This is defined by RFC 6509. Ticket (TICKET) provides a cryptographic token to request key material from an external server (KMS). This is defined by RFC 6043. Finally, the MIKEY message may contain an authentication payload. These include:
Signature (SIGN) a signature on the MIKEY message. Verification (V) a MAC sent by the receiver to verify receipt.