Mechanisms for certificate revocation status verification on constrained devices

A process is provided for communication security certificate revocation status verification by using the client device as a proxy in online status verification protocol. The process utilizes a nonce of an authentication protocol request message (nonce_A) to derive the nonce for the revocation status protocol request (nonce_S) to reduce the number of message exchanges needed between the client and the verifier devices, and a mechanism to send the nonce (nonce_S) prior to actual authentication protocol execution to ease the connectivity requirement of client device from on-demand connectivity to periodic connectivity. Similar functionality is achieved using a random seed established between the verifier and client. The verifier picks a seed for random number generation and sends that seed to the client. The client derives the nonce_S from the seed before status protocol execution, and the verifier derives the nonce_S from the seed before proxied status response verification.

TECHNOLOGICAL FIELD

An example embodiment of the present invention is related to the field of communications security; in particular, the provision of security certificates to users of communication resources and verification protocols for authenticating said certificates.

BACKGROUND

Public key certificates are commonly used for authentication of principals, such as devices and users. A public key certificate binds a public part of an asymmetric key pair to an identifier of the certified principal. The certificate is issued by a trusted Certificate Authority (CA) that signs the certificate. The certificate also contains a certificate identifier, such as certificate serial number. Each certified principal should store the private part of the asymmetric key securely.

If the private key of any principal is compromised (e.g., extracted from the device by an attacker and published online), anyone can masquerade as the certified principal using the issued certificate and the compromised private key. Thus, in case of noticed key compromise, the corresponding certificate should be revoked and the corresponding revocation information should be distributed to the relevant parties. Two well-known mechanisms for certificate revocation exist.

First, the CA maintains and periodically publishes a Certificate Revocation List (CRL). Such lists are defined in common X.509 certificate standard [X509]. A CRL contains a list of certificate identifiers, typically certificate serial numbers that have been revoked by the CA. The CRL is typically signed by the CA that issued the revoked certificates, or by another trusted entity authorized by the CA. A CRL also contains a timestamp. Using this timestamp the CRL verifier can check that the CRL is sufficiently recent.

Second, a certificate verifier can query the revocation status of a certificate from an online service that is maintained by the CA, or another trusted entity authorized by the CA. The responses to such online queries are signed by the trusted authority. The Online Certificate Status Protocol (OCSP) is a standardized protocol for such online queries. The freshness of OCSP responses can be guaranteed in two ways: (a) an OCSP request can contain a random nonce that should be included with the signed OCSP response, or (b) the OCSP response can contain a timestamp similar to CRLs.

The above mentioned well-known mechanisms for handling certificate revocation assume that (a) the certificate verifier has online connectivity and/or (b) the verifier knows the current time in a reliable manner. Online connectivity is needed for fetching the latest CRL from an online directory and for checking the revocation status of the certificate with an online service. The current time is needed to determine that the timestamp in a CRL or in an OCSP response is sufficiently recent.

There are practical use cases in which the certificate verifier has no connectivity to infrastructure networks or has no access to a reliable source of the current time. As such, how is the certificate revocation status securely verified from such constrained devices in an efficient manner in the context of execution of an authentication protocol.

By way of an example, a system model is defined in the following way: assume that two entities are engaged in an authentication protocol: a client device wishes to authenticate itself towards a verifier. Assume that the verifier has no direct connectivity to infrastructure networks and possibly no access to a reliable source of time. The client device has constant or periodic network connectivity. In an authentication protocol run, the verifier sends an authentication request with a random nonce and the client device replies with an authentication response that contains a signature calculated over the nonce and other information relevant for this particular authentication protocol, and a certificate.

MirrorLink [ML-ARCH] is a system that enables integration of mobile device provided services and content to infotainment systems in cars. In the MirrorLink system, the car head-unit (verifier) needs to authenticate, or attest, that the mobile device (client) is manufactured by a compliant mobile device manufacturer and that the mobile device is running compliant MirrorLink software. The primary reasons why such verification is needed are driving safety and liability issues. In the MirrorLink system, this authentication is achieved with a straight-forward device attestation protocol (DAP) that follows the model outlined above using a certified device key issued by the mobile device manufacturer.

In some cases, mobile devices may have only periodic connectivity to infrastructure networks. A mobile device that is roaming in a foreign country is an example scenario: cellular connectivity might be blocked or unavailable but periodic WiFi access through hotspots is usually available. Therefore, even from mobile devices, it is not possible for applications to always expect connectivity on-demand. A typical car head-unit has no direct connectivity to infrastructure networks. A typical head-unit has no reliable source of time information either. In a typical head-unit, a malicious user could reset or modify the head-unit clock from the head-unit user interface. Also situations in which the car main battery runs out may cause the head-unit clock to be reset. Such head-unit clock modifications are a relevant attack vector in systems like MirrorLink because the owner of the car may have an incentive to try to circumvent the MirrorLink device attestation model, in order to use non-compliant mobile devices or services while driving.

Although the MirrorLink system is the primary use case addressed in this description, the problem is not limited to the MirrorLink system only. Instead, similar revocation problems exist in other systems in which the verifier device has no connectivity and no reliable clock.

As such, it remains an open question as to how to design an efficient certificate revocation/freshness checking scheme that can work from a verifier device (e.g., car head unit) with (a) no online connectivity of its own and (b) no reliable way to determine current time, by using the help of a client device (e.g., mobile phone) which itself may have periodic network connectivity but cannot always provide network connectivity on-demand.

BRIEF SUMMARY

In a first embodiment, a process comprises using a nonce of an authentication protocol request message to derive a nonce for a revocation status protocol request. The nonce of the authentication protocol request becomes an operator of a key derivation function to derive a secure nonce. The number of messages necessary to exchange between a verifier device and a client proxy device may be reduced to two for a single authentication protocol request.

In an alternative embodiment, a process comprises receiving a random nonce at a client device from a verifier device before authentication protocol execution; obtaining revocation status information using the random nonce in the client device when network connectivity is available, and executing the authentication protocol between the verifier device and the client device. The process further comprises starting a timer when the random nonce is sent to the client device.

In another embodiment, a process comprises receiving a random seed value at a client device from a verifier device, deriving at the client device a revocation status nonce for a revocation status protocol request, verifying an authentication protocol response with an authentication protocol nonce received from a verifier device, and verifying the revocation status response with the revocation status nonce. The process further comprises starting a timer when the seed for the revocation nonce is sent to the client device.

Another embodiment may take the form of an apparatus comprising at least a processor, and a memory associated with the processor having computer coded instructions therein with the computer instructions being configured to, when executed by the processor, cause the apparatus to use a nonce of an authentication protocol request message to derive a nonce for a revocation status protocol request. The nonce of the authentication protocol request becomes an operator of a key derivation function to derive a secure nonce. The number of messages necessary to exchange in an authentication protocol may be reduced to two for a single authentication protocol request.

An alternative embodiment may be an apparatus comprising at least a processor, and a memory associated with the processor having computer coded instructions therein, with the computer instructions being configured to, when executed by the processor, cause the apparatus to receive a random nonce at a client device before authentication protocol execution; obtain revocation status information using the random nonce in the client device when network connectivity is available, and execute the authentication protocol. The process further comprises starting a timer when the random nonce is sent to the client device.

A further embodiment may be an apparatus comprising at least a processor, and a memory associated with the processor having computer coded instructions therein with the computer instructions configured to, when executed by the processor, cause the apparatus to receive a random seed value at a client device, derive at the client device a revocation status nonce for a revocation status protocol request, verify an authentication protocol response with an authentication protocol nonce, and verify the revocation status response with the revocation status nonce.

In a further embodiment, a computer program product is provided that comprises a non-transitory computer readable medium having computer program instructions stored therein, said instructions when executed by a processor causing a mobile terminal to use a nonce of an authentication protocol request message to derive a nonce for a revocation status protocol request. The nonce of the authentication protocol request becomes an operator of a key derivation function to derive a secure nonce. The number of messages necessary to exchange in an authentication protocol may be reduced to two for a single authentication protocol request.

In another embodiment, a computer program product is provided that comprises a non-transitory computer readable medium having computer program instructions stored therein, said instructions when executed by a processor causing a mobile terminal to receive a random nonce at a client device before authentication protocol execution; obtain revocation status information using the random nonce in the client device when network connectivity is available, and execute the authentication protocol. The process further comprises starting a timer when the random nonce is sent to the client device.

Another embodiment may be a computer program product comprising a non-transitory computer readable medium having computer program instructions stored therein, said instructions when executed by a processor causing a mobile terminal to receive a random seed value at a client device, derive at the client device a revocation status nonce for a revocation status protocol request, verify an authentication protocol response with an authentication protocol nonce, and verify the revocation status response with the revocation status nonce.

In yet another embodiment, an apparatus is provided that includes means for using a nonce of an authentication protocol request message to derive a nonce for a revocation status protocol request. The nonce of the authentication protocol request becomes an operator of a key derivation function to derive a secure nonce. The number of messages necessary to exchange between a verifier device and a client proxy device may be reduced to two for a single authentication protocol request.

In another embodiment, an apparatus includes means for receiving a random nonce at a client device from a verifier device before authentication protocol execution; means for obtaining revocation status information using the random nonce in the client device when network connectivity is available, and means for executing the authentication protocol between the verifier device and the client device. The apparatus may further include means for starting a timer when the random nonce is sent to the client device.

In further embodiment, an apparatus includes means for receiving a random seed value at a client device from a verifier device, means for deriving at the client device a revocation status nonce for a revocation status protocol request, means for verifying an authentication protocol response with an authentication protocol nonce received from a verifier device, and means for verifying the revocation status response with the revocation status nonce. The apparatus may further include means for starting a timer when the seed for the revocation nonce is sent to the client device.

DETAILED DESCRIPTION

This definition of “circuitry” applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term “circuitry” would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term “circuitry” would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or application specific integrated circuit for a mobile phone or a similar integrated circuit in server, a cellular network device, or other network device.

Although the method, apparatus and computer program product of example embodiments of the present invention may be implemented in a variety of different systems, one example of such a system is shown inFIG. 1, which includes a mobile terminal8that is capable of communication with a network6(e.g., a core network) via, for example, an radio network controller (RNC)2. While the network may be configured in accordance with a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), the network may employ other mobile access mechanisms such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), wideband code division multiple access (W-CDMA), CDMA2000, global system for mobile communications (GSM), general packet radio service (GPRS) and/or the like.

The network6may include a collection of various different nodes, devices or functions that may be in communication with each other via corresponding wired and/or wireless interfaces. For example, the network may include one or more base stations, such as one or more node Bs, evolved node Bs (eNBs), access points, relay nodes or the like, each of which may serve a coverage area divided into one or more cells. For example, the network may include one or more cells, including, for example, the RNC2, each of which may serve a respective coverage area. The serving cell could be, for example, part of one or more cellular or mobile networks or public land mobile networks (PLMNs). In turn, other devices such as processing devices (e.g., personal computers, server computers or the like) may be coupled to the mobile terminal and/or the second communication device via the network.

The mobile terminal8may be in communication with each other or other devices via the network6. In some cases, each of the mobile terminals may include an antenna or antennas for transmitting signals to and for receiving signals from a base station. In some example embodiments, the mobile terminal8, also known as a client device, may be a mobile communication device such as, for example, a mobile telephone, portable digital assistant (PDA), pager, laptop computer, tablet computer, or any of numerous other hand held or portable communication devices, computation devices, content generation devices, content consumption devices, universal serial bus (USB) dongles, data cards or combinations thereof. As such, the mobile terminal8may include one or more processors that may define processing circuitry either alone or in combination with one or more memories. The processing circuitry may utilize instructions stored in the memory to cause the mobile terminal to operate in a particular way or execute specific functionality when the instructions are executed by the one or more processors. The mobile terminal8may also include communication circuitry and corresponding hardware/software to enable communication with other devices and/or the network14.

Referring now toFIG. 2, an apparatus20that may be embodied by or otherwise associated with a mobile terminal8device (e.g., a cellular phone, a personal digital assistant (PDA), smartphone, tablet computer or the like) or a verifier device as discussed below may include or otherwise be in communication with a processor22, a memory device24, a communication interface28, and a user interface30.

In some example embodiments, the processor22(and/or co-processors or any other processing circuitry assisting or otherwise associated with the processor) may be in communication with the memory device24via a bus for passing information among components of the apparatus20. The memory device24may include, for example, one or more non-transitory volatile and/or non-volatile memories. In other words, for example, the memory device24may be an electronic storage device (e.g., a computer readable storage medium) comprising gates configured to store data (e.g., bits) that may be retrievable by a machine (e.g., a computing device like the processor). The memory device24may be configured to store information, data, content, applications, instructions, or the like for enabling the apparatus to carry out various functions in accordance with an example embodiment of the present invention. For example, the memory device could be configured to buffer input data for processing by the processor. Additionally or alternatively, the memory device24could be configured to store instructions for execution by the processor22.

In some example embodiments, such as instances in which the apparatus20is embodied by a mobile terminal8, the apparatus may include a user interface30that may, in turn, be in communication with the processor22to receive an indication of a user input and/or to cause provision of an audible, visual, mechanical or other output to the user. As such, the user interface may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen(s), touch areas, soft keys, a microphone, a speaker, or other input/output mechanisms. Alternatively or additionally, the processor may comprise user interface circuitry configured to control at least some functions of one or more user interface elements such as, for example, a speaker, ringer, microphone, display, and/or the like. The processor and/or user interface circuitry comprising the processor may be configured to control one or more functions of one or more user interface elements through computer program instructions (e.g., software and/or firmware) stored on a memory accessible to the processor (e.g., memory device and/or the like).

In regards to optimization to proxy verification, one technique to achieve certificate revocation status verification is to let the client device (also referenced as a client), such as a mobile terminal8, act as a proxy in online status verification protocol. This approach is illustrated inFIG. 3. The normal authentication protocol10is executed first and the verifier device (also referenced as a verifier), such as processor22of the verifier device, then extracts the client certificate from the authentication protocol response and runs an online verification status check12for this certificate mediated, or proxied, by the client device, such as the processor22or communications interface28of the client device, that has network connectivity14. In both the authentication protocol10and the revocation status protocol12, the freshness of response messages is guaranteed by including a random nonce (picked by the verifier). This mechanism has two major limitations: First, the client device needs immediate, on-demand connectivity at the time of authentication protocol run. Second, two complete message round-trips between client device and verifier are needed.

A first embodiment of an improved process is a mechanism to integrate the execution of the authentication protocol to the execution of the certificate verification status protocol in a manner that reduces the number of messages that needs to be exchanged between the client device and the verifier. This process uses the nonce of the authentication protocol request message43(nonce_A) to derive the nonce for the revocation status protocol request45(nonce_S). This approach is illustrated inFIG. 4, in which KDF( ) stands for key derivation function. This optimization guarantees freshness of both authentication protocol response40and revocation status response42and decreases the number of messages that need to be sent between the verifier device and the client device. However, this optimized version still retains the main limitation of the basic mechanism: the client device must have on-demand connectivity at the time of the authentication protocol run.

A second embodiment provides an improved verification process protocol without on-demand connectivity. The second embodiment is a way of combining an authentication protocol with a certificate revocation status protocol in a way that the client device needs only periodic network connectivity. The basic idea of this approach is illustrated inFIG. 5. In this process, the verifier device, such as the processor22of the verifier device, picks a random nonce51(nonce_S) and sends it52to the client device before authentication protocol execution. At any later point in time, when the client device has infrastructure network connectivity, the client device, such as the processor22or the communication interface28of the client device, may fetch the latest revocation status information54using this nonce51in the status verification protocol request. Later, the authentication protocol56can be executed between the verifier device and the client device without immediate, on-demand online connectivity.

Upon receiving authentication protocol response and revocation status protocol response, the verifier device, such as the processor22of the verifier device, checks that nonce_S is sufficiently recent. The verifier device, such as the processor22of the verifier device, therefore starts a timer when nonce_S is sent to the client52. Thus, the verifier is able to run a timer as long as it powered, but a persistent reliable clock that resists power breaks and user manipulation is not required. This would be the case with many car head-units, for example. The maximum allowable time window58between nonce_S generation and status response verification55depends on the use case at hand.

Alternatively, in another embodiment, similar functionality can be achieved by using a random seed that is established between the verifier and the client. This approach is illustrated inFIG. 6. The verifier, such as the processor22of the verifier device, can pick a seed61for random number generation and send that seed62to the client. The client, such as the processor22of the client device, can derive64the needed nonce_S63from the seed before status protocol execution, and the verifier, such as the processor22of the verifier device, can derive67the same nonce_S from the same seed before proxied status response verification.

To summarize, example embodiments may provide a mechanism to utilize a nonce of an authentication protocol request message (nonce_A) to derive the nonce for the revocation status protocol request (nonce_S) to reduce the number of message exchanges needed between the client and the verifier devices, and a mechanism to send the needed nonce (nonce_S) prior to actual authentication protocol execution to ease the connectivity requirement of client device from on-demand connectivity to periodic connectivity.

A more detailed and generalized description of the identification process is given inFIG. 7. For each authentication protocol run, it is not necessary to send a previous separate nonce message, as is done inFIG. 5. Instead, the needed status protocol nonce (nonce_Sx_next)72can be derived from a nonce that is included in a previous authentication protocol request (nonce_Sx)74. The authentication protocol request message can also contain a flag76(pflag) that defines whether a cached status response81can be used, or whether a new status response should be obtained83using the nonce that is included with this authentication request.

For the first authentication protocol run78between the verifier and the client device there is no previous nonce, and thus this flag should be set to false. The flag should be set to false also if too much time has elapsed since the previous nonce was sent, or if the verifier device clock has been reset since the previous nonce was sent. Otherwise, the flag may be set to true provided that the timer is running and has not expired and there is a cached StatusResp(nonce_S_next) for use in the verifier status exchange.

In one practical embodiment, the authentication protocol could be MirrorLink device attestation protocol (DAP) and the revocation status protocol would be OCSP. Thus the authentication request (AuthReq) message could take the format of AttestationRequest from [ML-DAP] and the authentication response (AuthRes) could take the format of AttestationResponse from [ML-DAP]. The AttestationRequest message format facilitates one nonce. In a generic embodiment (FIG. 7) the AuthReq message should contain two nonces and a flag. In such an implementation, the current AttestationRequest message format should be extended for the extra nonce and the flag.

In similar manner, the revocation status request (StatusReq) could be OCSPRequest with id-pkix-ocsp-nonce extension used for the nonce as specified in [OCSP]. The revocation status response (StatusResp) could be OCSPResponse as specified in [OCSP]. No changes to OCSP protocol or message formats would be needed.

In this regard, a first embodiment provides an optimized version of proxied revocation status verification. On-demand connectivity from the client is needed.

Additionally or alternatively, a second embodiment provides proxied revocation status verification in which only periodic connectivity from the client device is needed. This mechanism requires one extra message (sending nonce_S or seed prior to authentication protocol run). Otherwise, no changes to existing protocols are needed. The generalized format shows how a nonce can be derived from previous message exchange (and thus no extra messages are needed). This generalized mechanism typically would require updates to authentication protocol request message formats (such as AttestationRequest in MirrorLink DAP).

Referring to the flow diagrams of the various embodiments of the methods of certificate revocation verification described herein,FIG. 8is a flow diagram of a first embodiment of the method. The client device receives nonce_A801in the authentication protocol request signal. The client device then derives a secure nonce_S803using the key derivation function. The revocation status protocol is executed805over a network connection using nonce_S as the secure token. Finally, the client device sends the authorization protocol response807with nonce_A (from the verifier) and nonce_S in the response.

Referring toFIG. 9an alternative embodiment is illustrated. The client device receives nonce_S901directly from the verifier. Once the client device establishes a network connection it executes the revocation protocol using nonce_S903. Then it executes the authentication protocol905with nonce_A in the authentication response and nonce_S in the revocation response.

FIG. 10illustrates another embodiment of the method. In this embodiment the process starts with the client device receiving a random seed1001from the verifier. The client device derives a secure nonce_S1003from the random seed. Then the revocation protocol is executed1005using nonce_S whenever there is network connectivity in the client device. Once the revocation protocol has been executed, the authentication protocol can follow with nonce_A in the authentication response1007and nonce_S in the revocation status response.

FIG. 11shows yet another embodiment of the method. The client device receives nonce_So1101from the verifier, which starts a timer at that point. Then the client derives nonce_So_next1103. The revocation status protocol is executed1105using nonce_So_next as the token. When an authentication protocol request is received1107, a flag is checked for true/false condition1109. The flag is true if the timer has not expired and provided there is a cached value of nonce_So_next. If so, the authentication protocol is completed1111using nonce_So_next as the token exchanged. If the flag was false, a new revocation status protocol would be executed1113with nonce_S1(received in the authentication request) and the authentication request completed1115with nonce_S1in the exchange.

The following abbreviations appear in the above description and may be found in the claims.

CA certificate authority

CCC Car Connectivity Consortium

CRL certificate revocation list

OCSP Online Certificate Status Protocol

X.509 certificate standard

As described above,FIGS. 8-10are flowcharts of a method, apparatus and program product according to example embodiments of the invention. It will be understood that each block of the flowcharts, and combinations of blocks in the flowcharts, may be implemented by various means, such as hardware, firmware, processor, circuitry and/or other device associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures described above may be stored by a memory device24of an apparatus20employing an embodiment of the present invention and executed by a processor22in the apparatus. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (e.g., hardware) to produce a machine, such that the resulting computer or other programmable apparatus embody a mechanism for implementing the functions specified in the flowchart blocks. These computer program instructions may also be stored in a non-transitory computer-readable storage memory (as opposed to a transmission medium such as a carrier wave or electromagnetic signal) that may direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture the execution of which implements the function specified in the flowchart blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart block(s). As such, the operations ofFIGS. 8-10, when executed, convert a computer or processing circuitry into a particular machine configured to perform an example embodiment of the present invention. Accordingly, the operations ofFIGS. 8-10define an algorithm for configuring a computer or processing circuitry (e.g., processor) to perform an example embodiment. In some cases, a general purpose computer may be configured to perform the functions shown inFIGS. 8-10(e.g., via configuration of the processor), thereby transforming the general purpose computer into a particular machine configured to perform an example embodiment.