Method for authenticating Project 25 OTAR Key Management Messages with public key signature
Original Publication Date: 2010-Mar-27
Included in the Prior Art Database: 2010-Mar-27
Senese, Thomas: INVENTOR [+3]
This invention allows OTAR devices to automatically fall back into using public key signature for message integrity when normal MAC authentication is not possible. It assumes that the radios and KMF possess their own digital certificate, private signing key and trust anchor certificate. The method for acquiring these objects is outside the scope of this invention. The recipient of an OTAR command will first determine whether the received KMM is authenticated with a MAC. If not, then the recipient shall use its preconfigured security policy to determine whether it is allowed to process an unauthenticated KMM. Note that the P25 standard allows for some KMMs to be unauthenticated. A recipient that is not allowed to process an unauthenticated KMM will reject the message and then send the OTAR Negative Acknowledgement (NACK) to the originator. If the received KMM includes a MAC, the recipient will check whether it possesses a matching key to process the MAC. If the recipient has such a key, it shall process the received KMM, and respond in kind to the originator. If the received OTAR KMM does not have a MAC, or if there is no matching key for the MAC used by the originator, the recipient will send an OTAR NACK to the originator that includes a status indicating the message should be re-transmitted with a digital signature. This requires a new status type to be added to the KMM Status primitive field, defined in TIA 102.AACA (P25 OTAR Protocol). A flow diagram of the recipient?s operation is shown in Figure 1 (see attached document. Upon receiving the OTAR NACK, the originator resends the original OTAR command with a digital signature if it determines it can do so. The digital signature is generated using the originator?s private key. The recipient validates the signature by using the originator?s public key. The public key is found in the originator?s digital certificate. Before using the originator?s public key, the recipient must validate the originator?s digital certificate. It does so by validating the signature of the certificate?s signing authority. This requires the recipient to be preconfigured with the signing authority?s trust anchor certificate. Finally, the recipient must verify the revocation status of the originator?s digital certificate. It does so by checking the published list of revoked certificates on the Certificate Revocation List (CRL). If the originator is a radio, it need not send its certificate and CRL to the KMF. It is assumed that the KMF has an online connection to a repository where the radio?s certificate and CRL can be looked up. An example where the originator is a radio, and the radio needs to resend the original OTAR command with a digital signature is found in Figure 2 (see attached document). The preceding use case can also take place when the radio does not initially have a KEK or TEK. This condition may arise after an OTAR Zeroize operation takes place in order to address a possible key compromise situation. After the Zeroize procedure completes, the radio will not possess a TEK or KEK. However, the radio will retain its public/private key pair through the Zeroize procedure. In Figure 2a (see attached document), the KMF sends a new embodiment of the Warm Start KMM, which contains both a Warm Start TEK and Warm Start KEK. The TEK and KEK are wrapped with the radio?s public key. The current Warm Start KMM contains a reserved byte. This reserved field can be used to indicate that a Warm Start KEK is also included in the payload. The Warm Start TEK and Warm Start KEK are ephemeral. They can be used to protect a subsequent Rekey KMM, which includes a longer lived TEK and KEK as the payload. Once the longer-lived TEK and KEK are received through the Rekey KMM, the radio automatically deletes the Warm Start TEK and Warm Start KEK. There are also two alternate embodiments to the case (Fig. 2a - see attached document) where a radio without a TEK and KEK attempts a rekey request: i. A new KEK Warm Start KMM is used to distribute the Warm Start KEK to the radio after the KMF distributes the Warm Start TEK through the Warm Start KMM. ii. No Warm Start KEK is used. Rather, the key wrapping of the Rekey KMM uses public key crypto with the radio?s public key. The payload of the Rekey KMM includes the radio?s KEK, and a long lived TEK. The outer-layer encryption of the Rekey KMM uses the Warm Start TEK. The Warm Start KMM includes an Algorithm ID field that indicates the algorithm used for key wrapping. A new Algorithm ID value will indicate that public key is used for the key wrapping. If the originator is the KMF, it must send its certificate and CRL to the radio, along with the original OTAR command. It is assumed that the radio will not have access to a repository for the KMF?s certificate and CRL. An example where the originator is a KMF, and the KMF needs to resend the original OTAR command with a digital signature, along with its certificate and CRL, is found in Figure 3 (see attached document). Summary of Major Claims 1. Recipient of an unauthenticated OTAR command indicates its desire to have the message resent with a digital signature through a status in the OTAR NACK. 2. Originator of a rejected, unauthenticated OTAR command resends the command with a digital signature upon request from the recipient. 3. In the case where a radio does not have a KEK, the KMF sends the Warm Start KMM which includes a Warm Start KEK in addition to the Warm Start TEK. The Warm Start K
Method to authenticate Project 25 OTAR Key Management Messages with public key signature
By Tom Senese, Obaid Shahab, Helen Hoselton, Tim Woodward
Enterprise and Mobility Solutions
This document specifies a method to authenticate Project 25 Key Management Messages (KMMs) when Traffic Encryption Keys (TEKs) are not available. The Project 25 Over-The-Air-Rekeying (OTAR) standard uses TEKs for KMM authentication.
Project 25 TEKs are symmetric keys. As a result, both the sender and recipient of a KMM must possess the same TEK in order for the KMM authentication to successfully take place. There are some exception cases identified by the Project 25 OTAR standard where the sender and recipient do not possess the same TEK. For such scenarios, the P25 OTAR standard allows the exchange of KMMs to take place without authentication.
This document describes a solution to authenticate KMMs when the sender and recipient do not share a common TEK. The solution is based off the use of public key digital signatures.
Project 25 Key Management Messages (KMMs) are used to conduct key management operations, including key transfer, between a Key Management Facility (KMF) and subscriber radio. Message integrity and source authentication of the KMMs is provided by the Message Authentication Code (MAC). The requirements and protocol definitions for using the KMM MAC can be found in TIA 102.AACA-1, section 5.4.
The Project 25 KMM is used to support key management operations for symmetric keys, which include Traffic Encryption Keys (TEKs) and Key Encryption Keys (KEKs). The MAC key is also a symmetric key. It is either a dedicated key that is shared between the KMF and subscriber radio, or it is derived from one of the radio’s TEKs using a well known algorithm.
There are some exception conditions where the subscriber radio may not currently have any TEKs, but still needs to conduct key management operations with the KMF. One scenario is where the radio user plans to give the radio to another user, or to a service shop. The common procedure is to manually erase the current TEKs in the radio before handing it over to the other user or service shop. When the owner gets the radio back, he or she may initiate a rekey request with the KMF in order to get new TEKs. This rekey request is transmitted without MAC authentication. As a result, the KMF can not verify the authenticity of the received rekey request.
The TIA 102.AACA-2 standard allows the following KMMs to be sent without a MAC in scenarios where the subscriber radio does not have a TEK, or a dedicated symmetric key, that can be used to generate the MAC.
- Capabilities Command
- Capabilities Response
- No Service
Without MAC protection, these KMMs are susceptible to tampering or spoofing. Some possible attacks include the following:
1) attacker sends bogus Capabilities Command to the subscriber radio
In this case, the attacker sends an unencrypted Capabilities Command message,...