EP4162381A1

EP4162381A1 - System and method for maintaining a list of cryptographic certificates

Info

Publication number: EP4162381A1
Application number: EP21731593.6A
Authority: EP
Inventors: Renico KOEN
Original assignee: IotNxt BV
Current assignee: IotNxt BV
Priority date: 2020-06-03
Filing date: 2021-06-03
Publication date: 2023-04-12
Also published as: WO2021245600A1; ZA202213535B

Abstract

Systems and methods for maintaining cryptographic revocation lists are provided. A method includes determining that a cryptographic certificate (152) should be revoked. Based on the determination, a certificate revocation message is broadcast to a network of client devices (140). The certificate revocation message includes an identifier associated with the cryptographic certificate. Each client device that receives the certificate revocation message updates a list (144) maintained by the client device. The updated list indicates that the cryptographic certificate (152) identified by the identifier is no longer valid.

Description

SYSTEM AND METHOD FOR MAINTAINING A LIST OF CRYPTOGRAPHIC CERTIFICATES

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application number 2020/03302 filed on 3 June 2020, which is incorporated by reference herein.

FIELD OF THE INVENTION

The invention disclosed herein relates to systems and methods for maintaining a list of cryptographic certificates. If finds particular, although not exclusive application, in maintaining a list of cryptographic certificates used in secure network communications.

BACKGROUND TO THE INVENTION

Communication between computer network nodes may be vulnerable to interception by a third party if not secured by means of a communication security protocol, such as a cryptographic communication security protocol. Cryptographic communication security protocols serve to secure data transfer between network nodes, such as between a client and server, through authentication, encryption and integrity protection measures.

T ransport Layer Security (TLS) is one such cryptographic communication security protocol and is widely used in network communications and web applications such as web browsing sessions, file transfer, virtual private network (VPN) connections, remote desktop sessions, voice over IP (VoIP) and the like.

According to the TLS protocol specification it is composed of two layers: the TLS record protocol and the TLS handshake protocol. The record protocol provides connection security, while the handshake protocol allows the nodes (e.g. server and client) to authenticate each other and to negotiate encryption algorithms and cryptographic keys before any data is exchanged between them. During the handshake protocol, the one node (e.g. the client to continue the aforementioned example) advertises to the server what cryptographic algorithms or “ciphers” it supports; and the server then selects a preferred cipher from the advertised ciphers by means of which the communication session to follow will be encrypted and decrypted. The server then also sends its cryptographic certificate to the client for verification. The certificate is an electronic document that proves the identity of its owner and that is digitally signed by a trusted issuer or Certificate Authority (CA). The client may verify the identity of the server by confirming its validity from the Certificate Authority using the certificate sent to it during the handshake. The verification may include verifying that the certificate was indeed digitally signed by the CA; that the certificate is still valid in that an assigned validity period has not expired due to the effluxion of time; and whether the certificate has not been revoked by the CA. If the verification is successful the TLS communication session may be established, else it will be terminated.

The handshake transaction described above is that of a one-way TLS authentication in which only the server is authenticated by the client. However, a two-way TLS authentication may require that the server also authenticates the client in a similar manner. The client therefore verifies the certificate provided by the server and the server verifies the certificate provided by the client.

Provided that strict verification is performed, it would be possible for the CA to cryptographically revoke a node’s access to the network by simply revoking the certificate that was issued to it. In its simplest forms a certificate may for example be revoked by the CA using its unique serial number. Once revoked the serial number is placed on a list, referred to as a certificate revocation list. When a node needs to check whether the certificate of another node has been revoked, it can do so by downloading the revocation list from the CA and checking whether the certificate’s serial number is listed in the revocation list. If not found in the list the certificate may be accepted. Else, the certificate is rejected and the connection terminated.

Downloading certificate revocation lists every time a certificate needs to be verified may be cumbersome and resource intensive. To combat this problem, caching is typically implemented on network devices. A revocation list is downloaded periodically and kept on the device for a defined period, often several days. The validity period, and thus the revocation list refresh rate, is usually specified in the list by the CA. Thus, once the list expires, the device will be required to download it again from the CA before its next TLS handshake.

This presents a security vulnerability in that a revoked certificate could potentially be used freely in the system until the clients download the updated revocation list.

To overcome this problem a different model was proposed in which the CA is queried for the revocation status of a certificate using the Online Certificate Status Protocol (OCSP) protocol described in RFC6960. A device that needs to verify the revocation status of a certificate simply needs to send a query to an OCSP server and the OCSP server will respond by stating whether a certificate has been revoked or not. However, in the event that the relevant OCSP server may be offline or unavailable the node will be unable to perform certificate validation.

To combat the limitation that an OCSP server needs to be accessible to the client, another scheme has been proposed referred to as OCSP stapling”. This protocol shifts the responsibility of proving the certificate validity to the other party. That is, the party whose certificate requires verification must contact the OCSP server to get a signed statement proving that its certificate is valid.

The certificate and proof of its validity are returned to the client during the verification phase and the client therefore does not require access to the OCSP server to verify the certificate. Since OCSP stapling shifts the burden of proving its certificate validity to the server it may provide a benefit in the case of one-way TLS authentication. However, in the case of two-way TLS authentication both parties will again require access to the OCSP server which at least partly defeats the purpose of OCSP stapling.

Accordingly the Applicant considers there to be scope for improvement.

The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention there is provided a computer-implemented method for maintaining cryptographic revocation lists at client devices, the method performed at a server and comprising: determining that a cryptographic certificate should be revoked; based on the determination, causing a certificate revocation message to be broadcast to a network of client devices, the certificate revocation message including an identifier associated with the cryptographic certificate; wherein each client device that receives the certificate revocation message updates a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid.

The certificate revocation message may include a broadcast sequence indicator. Each client device that receives the certificate revocation message may compare the broadcast sequence indicator with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed. Upon determining that one or more intervening certificate revocation messages have been missed, a client device may request a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages. A full update may also be requested in response to the client device powering up, rebooting, or in response to the effluxion of time of a refresh period.

The broadcast sequence indicator may be a numeric indicator that is incremented with each certificate revocation message broadcast. Each client device that receives the certificate revocation message may compare the broadcast sequence indicator with a preceding broadcast sequence indicator by calculating the numeric difference thereof and determines that it had not missed any intervening certificate revocation messages if the difference is equal to the increment value.

The identifier associated with the cryptographic certificate may be a serial number of the certificate.

The certificate revocation message may be broadcast in a publisher-subscriber (pub/sub) messaging pattern. The client devices may receive the certificate revocation message in response to subscribing to the broadcasts.

The server may be a certificate authority (CA). ; Causing a certificate revocation message to be broadcast to the network of client devices may be preceded by sending the certificate revocation message to a notification server that, in turn, broadcasts the certificate revocation message.

The certificate revocation message may be digitally signed. Each client device that receives the certificate revocation message may update the list maintained by the client device if able to verify the digital signature of the message.

In accordance with a further aspect of the invention there is provided a computer-implemented method for maintaining a cryptographic revocation list at client devices, the method performed at a client device and comprising: receiving a certificate revocation message broadcast, the certificate revocation message including an identifier associated with a cryptographic certificate; and updating a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid, wherein the certificate revocation message is broadcast in response to a server determining that the cryptographic certificate should be revoked.

The certificate revocation message may include a broadcast sequence indicator. The client device may compare the broadcast sequence indicator of the certificate revocation message with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed. Upon determining that one or more intervening certificate revocation messages have been missed, the client device may request a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages. A full update may also be requested in response to the client device powering up, rebooting, or in response to the effluxion of time of a refresh period.

The broadcast sequence indicator may be a numeric indicator that is incremented with each certificate revocation message broadcast. The client device may compare the broadcast sequence indicator with a preceding broadcast sequence indicator by calculating the numeric difference thereof and determining that it had not missed any intervening certificate revocation messages if the difference is equal to the increment value.

The certificate revocation message may be broadcast in a publisher-subscriber (pub/sub) messaging pattern. Receiving a certificate revocation message broadcast may be preceded by subscribing to the broadcasts.

The certificate revocation message may be digitally signed by the server. The client device may update the list maintained by the client device if able to verify the digital signature of the message.

The method may include performing a cryptographic communication handshake with a remote client device during which a cryptographic certificate associated with the remote client device is received therefrom. The list maintained by the client device may be checked and communication terminated with the remote client device if the list indicates the cryptographic certificate as no longer being valid.

The client device may be a Transport Layer Security (TLS) client. The cryptographic communication handshake may be a TLS handshake. In accordance with a further aspect of the invention there is provided a system for maintaining a cryptographic revocation list at client devices, the system including a server having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the server comprising: a certificate revocation component for determining that a cryptographic certificate should be revoked; a publishing component for, based on the determination, causing a certificate revocation message to be broadcast to a network of client devices; and a message compiling component for including an identifier associated with the cryptographic certificate in the certificate revocation message to broadcast; wherein each client device that receives the certificate revocation message updates a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid.

The server may include a sequence component for including a broadcast sequence indicator in the certificate revocation message. Each client device that receives the certificate revocation message may compare the broadcast sequence indicator with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed. The server may include a request receiving component for, upon a client device determining that one or more intervening certificate revocation messages have been missed, receiving a request from a client device for a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

In accordance with a further aspect of the invention there is provided a system for maintaining a cryptographic revocation list at client devices, the system including a client device having a memory for storing computer-readable program code and a processor for executing the computer- readable program code, the client device comprising: a subscribing component for receiving a certificate revocation message broadcast, the certificate revocation message including an identifier associated with a cryptographic certificate; and a list maintaining component for updating a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid, wherein the certificate revocation message is broadcast in response to a server determining that the cryptographic certificate should be revoked. The certificate revocation message may include a broadcast sequence indicator. The client device may include a comparator component for comparing the broadcast sequence indicator of the certificate revocation message with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed. The client device may include a requestor component for, upon determining that one or more intervening certificate revocation messages have been missed, requesting a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

In accordance with a further aspect of the invention there is provided a computer program product for maintaining a cryptographic revocation list at client devices, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: determining that a cryptographic certificate should be revoked; based on the determination, causing a certificate revocation message to be broadcast to a network of client devices, the certificate revocation message including an identifier associated with the cryptographic certificate; wherein each client device that receives the certificate revocation message updates a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid.

Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings: Figure 1 is a schematic representation of a system for maintaining cryptographic certificate revocation lists at client devices;

Figure 2 is a swim-lane flow chart of a method for maintaining cryptographic certificate revocation lists at client devices;

Figure 3 is a block diagram showing functional units of a certificate authority; Figure 4 is a block diagram showing functional units of a client device; and

Figure 5 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Methods and systems for maintaining cryptographic certificate revocation lists at client devices are described below. In a method, a determination is made that a cryptographic certificate should be revoked. The determination may be made by a certificate authority (CA) or another trusted entity with the requisite authority in the public key infrastructure (PKI) of a particular network. A certificate revocation message is broadcast to a network of client devices in response to the determination that the certificate is to be revoked. The server that makes the determination that the certificate should be revoked may instruct an intermediary to broadcast the certificate revocation message to the network of client devices.

The broadcasts may be by means of a publisher-subscriber (pub/sub) messaging pattern. This may require client devices to subscribe to the broadcasts using topic-based or content-based filtering, for instance, in order to receive the certificate revocation message broadcasts. Other messaging patterns may also be utilised, such as an observer messaging pattern, IP multicasting, UDP broadcasts, and the like.

The certificate revocation message includes an identifier associated with the cryptographic certificate, which may be a serial number of the certificate. Each client device that receives the certificate revocation message updates a register list maintained by the client device in a memory accessible thereby, optionally stored in an on-board memory of the client device in a cached manner, to indicate in the updated list that the cryptographic certificate identified by the identifier is no longer valid. The certificate revocation message is broadcast asynchronously and in an event-driven manner from the server side, the trigger event being the revocation of the certificate or the determination that it should be revoked. The certificate revocation message may preferably be broadcast by the server without significant delay, and as near to instantaneous as normal processing and transmission latencies may allow. The broadcast propagates from the server to the client devices in the network of client devices simultaneously, or as near as simultaneously as processing and transmission latencies may allow. This may be preferable to minimise the probability that a client device may refer to its cached list of revoked certificates and inadvertently allow communication with the device that is the owner of the revoked certificate. While it may be preferable for the certificate revocation message to be broadcast near-instantaneously, it may occur that two or more certificates are revoked in rapid succession, in which case the certificate revocation message broadcast may include identifiers of these two or more certificates.

The method by no means excludes the CA or other PKI entity to be polled by any one of the network of client devices intermittently for an update of a list of revoked certificates. This may be to satisfy start-up conditions of the relevant device, or to mitigate the possibility of missed broadcasts while having been in a disconnected or powered-down state; or as a redundancy measure. In a broadcast-type message pattern, the broadcaster or publisher may not receive an acknowledgement of receipt from the client devices and having the client devices intermittently polling for a list of revoked certificates may provide a fail-safe.

The certificate revocation message broadcast may have measures built-in thereto to enable the client devices to determine whether or not they may have missed any intervening broadcasts (which would require them polling the CA for an update). In one embodiment, the revocation broadcast message may include a counter, or broadcast sequence, that is incremented by a value known to the client devices on each broadcast. The certificate revocation message may also indicate the increment value, enabling it to be changed from time to time as a security feature. The sequence number may also be a timestamp representing a time at which the certificate revocation message is broadcast.

Each client device may therefore store the broadcast sequence upon receiving a certificate broadcast message. It may compare the broadcast sequence of a received message to that of a preceding message and, if the numeric difference in these broadcast sequences does not equal the increment value, it may determine that it had missed a certificate broadcast message. If so, the relevant client device may poll the server for a revoked certificate list update. In one embodiment, the client device may poll the server for a complete revoked certificate list. In another embodiment, it may poll it only for the missed broadcasts. To enable this, it may include the broadcast sequence of a preceding received broadcast (i.e. before the broadcast during which it determined that it had missed previous broadcasts) in the poll to the server. The server may maintain a register of previous certificate revocation message broadcasts and may, upon receiving a poll from a client device for an update, prepare and send an update comprising the subject matter of all the certificate revocation messages broadcast after the broadcast sequence received from the client device.

The identifier associated with the cryptographic certificate, optionally its serial number, may allow the client device to perform a lookup in its list to check whether a particular cryptographic certificate is indicated as being revoked or no longer valid according to its own, cached, list. The identifier may also be a cryptographic hash or a universally unique identifier associated with the certificate.

When establishing a cryptographically secured communication session with another client device (device B), a client device (device A) may receive a cryptographic certificate from the device B during a handshake sequence. Instead of either client device (A or B) querying a certificate authority to confirm the validity of the certificate, device A may perform a lookup in its own, cached, list of revoked cryptographic certificates maintained as described above. Should device A locate the certificate or an identifier thereof in its list, device A may terminate the communication session with device B.

Figure 1 shows a schematic representation of a system (100) for maintaining cryptographic revocation lists at client devices. The system (100) includes a certificate authority (CA) (110) that is trusted and authorised to issue digital certificates and, more particularly, cryptographic certificates. The CA (110) has access to a database (112) in which it maintains a list of cryptographic certificates (a certificate revocation list or CRL) that it had issued, but which has had its validity revoked prior to the expiry of its validity period. The reasons that may necessitate the revocation of a certificate’s validity may include that the relevant certificate had been compromised, or that the certificate had been superseded for example. The revocation state may be either irreversibly revoked or temporarily on hold (as specified in RFC 5280).

The system (100) further includes a publication server (120) with which the CA (110) is in communication through a network (130). The publication server (120) is configured to enable client devices to subscribe to publications broadcast thereby. In the present embodiment, the publication server (120) provides a publication service in the form of a publisher/subscriber (or pub/sub) message pattern. Figure 1 shows two such exemplary client devices, client device A (140) and client device B (150). Client devices A and B (140, 150) are subscribed to broadcast messages from the publication server (120) which it may filter according to the content or the topic of the broadcast.

Client device B (150) has a cryptographic certificate (152) issued to it by the CA (110) having a certain validity period. The certificate (152) enables the client devices (140, 150) to communicate (160) through a cryptographic communication protocol which in the present embodiment is the Transport Layer Security (TLS) protocol. It will be understood that the communication (160) between the two client devices (140, 150) is established through secure TLS network connections (162) via the network (130) and that the communication link (160) shown in Figure 1 is symbolic.

In the present scenario, client device B (150) may be a server device, and client device A (140) may be a client device for TLS communication purposes. The particular communication protocol in this embodiment also requires one-way TLS authentication in which the validity of the certificate (152) of the server, or client device B (150), must be verified during a TLS handshake procedure before the communication session (160) between the client devices will be established.

Client device A (140) has access to a local database (142) in which it maintains a cached list (144) of revoked certificates. If the CA (110) determines that a cryptographic certificate that it had issued should be revoked, it creates a certificate revocation message that includes an identifier associated with the certificate to be revoked. The CA (110) digitally signs the message with its own private key, and instructs the publication server (120) to broadcast the certificate revocation message to the client devices (140, 150). The CA (110) includes the revoked certificate in its own certificate revocation list maintained in its database (112).

Upon receiving the certificate revocation message broadcast from the publication server (120), the client devices, such as client device A (140) updates the locally cached list (144) of revoked certificates maintained thereby in its local database (142).

Subsequently, when a TSL communication session is initiated between client devices A and B (140, 150), the TLS handshake requires the TLS server certificate (152) to be verified. Client device A (140) as the TLS client may check its own list to determine whether the certificate (152) of client device B (150) (the TLS server) is included in its list of revoked certificates. If so, the TLS communication session (160) may be terminated by the TSL client (client device A (140)).

In a scenario where two-way TLS authentication is required, both the TLS server and client certificates’ authenticity need to be verified. It will be appreciated that, similarly as above, client device B (150) as the TLS server may maintain its own locally cached list of revoked certificates and may check its list during the TLS handshake as to whether the cryptographic certificate of client device A (140) had been revoked.

In some embodiments, the publication server (120) is not a separate entity to the CA (110), but is rather a subcomponent (possibly a software subcomponent) of the CA, as indicated by the broken line border shown in Figure 1 surrounding the CA and the publication server.

Figure 2 is a swim-lane flow chart of a method for maintaining a cryptographic certificate list in which the steps in the respective lanes indicate steps executed at the respective devices. The CA (110) determines (202) that a particular cryptographic certificate previously issued by it is to be revoked. In the present scenario, the cryptographic certificate (152) of client device B (150) is to be revoked. Possible reasons therefor include that the certificate had been compromised in that the corresponding private key of the certificate (152) may have been obtained by a third party. The CA (110) then creates (204) a certificate revocation message which includes at least an identifier associated with the certificate (152) to be revoked, such as its serial number. The message also includes a broadcast sequence, which is incremented with each broadcast. In the present embodiment, the broadcast sequence is an integer value that increments with each broadcast. The CA (1 10) also digitally signs the certificate revocation message to enable recipients to verify the authenticity thereof and the identity of the originator.

The CA (110) then instructs (206) the publication server (120) to broadcast the certificate revocation message which, in turn, broadcasts the message. The CA (110) updates its own certificate revocation list (in its database (112)) to indicate the certificate (152) as being revoked and stores the incremented broadcast sequence for future use.

For client devices to receive the certificate revocation broadcasts, the relevant devices need to firstly subscribe to this publication service of the publication server (120). To this end, client device A (140) subscribes (210) to receive the broadcasts and receives (212) the certificate revocation message broadcast. It checks (214) the broadcast sequence number against that of a previously received broadcast. If the numeric difference between the sequence numbers is greater than 1 (which is presently the broadcast sequence increment value), client device A (140) determines that it had missed one or more intervening certificate revocation message broadcasts and requests (216) an update from the CA (110). The update may either be a full update of the certificate revocation list held by the CA (110) in its database (112). However, the CA (110) may also maintain records in its database (112) of the subject matter contained in each broadcast, which enables the update include only the data relating to the intervening broadcasts missed by client device A (140). The CA (10) then sends (217) the update. Client device A (140) then updates (218) the certificate revocation list (144) maintained thereby to indicate that the certificate (152) is no longer valid. In the event that a certificate revocation list was requested (216), client device A (140) updates its list (144) with the sent (217) by the CA (110).

Subsequently, client device A (140), as a TLS client, attempts to establish a TLS communication session with client device B (150), as a TLS server. During the establishing of the TLS communication session, the client devices (140, 150) performs (220) a TLS handshake during which the validity of client device B’s certificate (152) is to be verified. Client device A (140) checks (222) whether its list (144) indicates the certificate (152) as no longer being valid and thus revoked. If it is found in the list (144), client device A (140) terminates (224) the TLS session.

In embodiments in which the publication server (120) is a subcomponent of the CA (110) the steps of the method (100) will be performed with the necessary changes. For example, in the step in which the CA (110) instructs (206) the publication server (120), the CA would issue the instruction to this publication server subcomponent.

Various components may be provided for implementing the method described above with reference to Figure 2. Figure 3 is a block diagram which illustrates exemplary components which may be provided by a server, particularly a certificate authority (CA), in a system for maintaining cryptographic certificate revocation lists at client devices

The CA (110) may include a processor (302) for executing the functions of components described below, which may be provided by hardware or by software units executing on the CA (110). The software units may be stored in a memory component (304) and instructions may be provided to the processor (302) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the CA (110) may be provided remotely.

The CA (110) includes a certificate revocation component (306) arranged to determine that a cryptographic certificate should be revoked. The CA (110) further includes a message compiling component (308) arranged to compile a certificate revocation message to be broadcast to a network of client devices, including an identifier associated with certificate to be revoked. The message compiling component (308) is further arranged to include a broadcast sequence, obtained from a sequence component (310), which increments on each broadcast. The compiled message, including the subject matter relating to the revoked certificate as well as the broadcast sequence, may be stored in a database (112) through a storage component (312). The CA (110) also includes a publishing component (314) arranged to cause the certificate revocation message compiled by the message compiling component (308) to be broadcast to client devices. In doing so, the publishing component (314) may instruct a separate publication server (120) through a network (130); or alternatively may instruct a publication server subcomponent (315) of the CA (110).

The CA (110) further includes a request receiving component (316) arranged to receive a request from a client device in response to it determining that it had missed an intervening broadcast. The message compiling component (308) is arranged to prepare a message including the information requested in the request received from the client device.

Figure 4 is a block diagram which illustrates exemplary components which may be provided by a client device (140) in a system for maintaining cryptographic certificate revocation lists at client devices. For ease of reference, the description of the client device will be performed with reference to client device A (140), however is equally applicable to client device B (150).

The client device (140) may include a processor (402) for executing the functions of components described below, which may be provided by hardware or by software units executing on the client device (140). The software units may be stored in a memory component (404) and instructions may be provided to the processor (402) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the client device (140) may be provided remotely.

The client device (140) includes a subscribing component (406) for subscribing to a publication server (120) and for receiving certificate revocation message broadcasts therefrom, originating from a CA (110) in response to the CA determining that a cryptographic certificate should be revoked. The client device (140) includes a storage component (408) for facilitating access to a database (142) in which the client device (140) maintains a list (144) of revoked certificates to indicate the certificates as no longer being valid. The client device (140) includes a list maintaining component (410) for updating the list (144) in response to the client device receiving a broadcast by means of its subscribing component (406).

The client device includes a comparator component (412) for comparing a broadcast sequence included in a broadcast message received by the subscribing component (406) with that of a previously received broadcast. The comparator component (412) is further arranged to instruct a requestor component (414) to request a certificate revocation list update from the CA (110) if the comparator component (412) determines that the client device (140) had missed an intervening certificate revocation message broadcast. The client device (140) includes a communications component (416) for establishing cryptographically secured communication sessions with other client devices (such as client device B (150)). In the present embodiment, the communications component (416) is arranged to establish TLS communication sessions, in which case it (although being a network client device) acts in the capacity of a TLS client; and client device B (150) (although being network client device) acts in the capacity of a TLS server.

The communications component (416) is therefore further arranged to perform a TLS handshake procedure during which the validity of the TLS server’s certificate (152) is verified. The client device (140) therefore further includes a list checking component (418) for checking the certificate revocation list (144) maintained thereby as to whether the list indicates the certificate a being revoked and therefore no longer valid. If the list checking component (418) determines (from checking the list (144)) that the certificate (152) of the TLS server (presently client device B (150)) is no longer valid, to instruct the communications component (416) to terminate the TLS communication session.

The methods and systems disclosed herein therefore enable certificate revocation lists to be maintained by each client device on a network and for their respective lists to be updated as and when a certificate authority revokes the validity of a cryptographic certificate initially issued thereby. Since a message is broadcast (or caused to be broadcast) by the CA near-immediately following the revocation of a certificate, the methods and systems enable the client devices’ locally maintained lists to be updated in an event-driven manner and my require the client devices to request a certificate revocation list from the CA only if it determines that its locally maintained list may not be up to date. It will be readily apparent that this may reduce the probability of the client device allowing a TLS session to be established with a server whose certificate had been revoked due to an outdated locally cached certificate revocation list of the client device.

What is more, it also enables the same mechanisms to be utilised for two-way TLS authentication in which TLS client confirms the validity of the TLS server; and vice versa.

This may therefore provide improved communication security in a network.

Figure 5 illustrates an example of a computing device (500) in which various aspects of the disclosure may be implemented. The computing device (500) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

The computing device (500) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (500) to facilitate the functions described herein. The computing device (500) may include subsystems or components interconnected via a communication infrastructure (505) (for example, a communications bus, a network, etc.). The computing device (500) may include one or more processors (510) and at least one memory component in the form of computer-readable media. The one or more processors (510) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (500) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.

The memory components may include system memory (515), which may include read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (515) including operating system software. The memory components may also include secondary memory (520). The secondary memory (520) may include a fixed disk (521 ), such as a hard disk drive, and, optionally, one or more storage interfaces (522) for interfacing with storage components (523), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

The computing device (500) may include an external communications interface (530) for operation of the computing device (500) in a networked environment enabling transfer of data between multiple computing devices (500) and/or the Internet. Data transferred via the external communications interface (530) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (530) may enable communication of data between the computing device (500) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (500) via the communications interface (530). The external communications interface (530) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuity.

The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (510). A computer program product may be provided by a non-transient computer-readable medium, or may be provided via a signal or other transient means via the communications interface (530).

Interconnection via the communication infrastructure (505) allows the one or more processors (510) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (500) either directly or via an I/O controller (535). One or more displays (545) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (500) via a display (545) or video adapter (540).

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention.

Finally, throughout the specification and claims unless the contents requires otherwise the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Claims

CLAIMS:

1. A computer-implemented method (200) for maintaining cryptographic revocation lists at client devices, the method performed at a server (110) and comprising: determining (202) that a cryptographic certificate (152) should be revoked; based on the determination, causing a certificate revocation message to be broadcast (206) to a network of client devices (140), the certificate revocation message including an identifier associated with the cryptographic certificate (152); wherein each client device that receives the certificate revocation message updates (218) a list (144) maintained by the client device, the updated list indicating that the cryptographic certificate (152) identified by the identifier is no longer valid.

2. The method as claimed in claim 1 wherein the certificate revocation message includes a broadcast sequence indicator, and wherein each client device (140) that receives the certificate revocation message compares the broadcast sequence indicator with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed.

3. The method as claimed in claim 2 wherein, upon a client device (140) determining that one or more intervening certificate revocation messages have been missed, the client device requests a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

4. The method as claimed in claim 2 or 3 wherein the broadcast sequence indicator is a numeric indicator that is incremented with each certificate revocation message broadcast, and wherein each client device that receives the certificate revocation message compares the broadcast sequence indicator with a preceding broadcast sequence indicator by calculating the numeric difference thereof and determines that it had not missed any intervening certificate revocation messages if the difference is equal to the increment value.

5. The method as claimed in any one of the previous claims wherein the identifier associated with the cryptographic certificate is a serial number of the certificate.

6. The method as claimed in any one of the previous claims wherein the certificate revocation message is broadcast in a publisher-subscriber (pub/sub) messaging pattern, wherein the client devices receives the certificate revocation message in response to subscribing to the broadcasts.

7. The method as claimed in any one of the previous claims wherein the server is a certificate authority (CA); and wherein causing a certificate revocation message to be broadcast to the network of client devices is preceded by sending the certificate revocation message to a notification server that, in turn, broadcasts the certificate revocation message.

8. The method as claimed in any one of the previous claims wherein the certificate revocation message is digitally signed, and wherein each client device that receives the certificate revocation message updates the list maintained by the client device if able to verify the digital signature of the message.

9. A computer-implemented method (200) for maintaining a cryptographic revocation list at client devices, the method performed at a client device (140) and comprising: receiving (212) a certificate revocation message broadcast, the certificate revocation message including an identifier associated with a cryptographic certificate (152); and updating (218) a list maintained by the client device (140), the updated list indicating that the cryptographic certificate (152) identified by the identifier is no longer valid, wherein the certificate revocation message is broadcast in response to a server (110) determining that the cryptographic certificate should be revoked.

10. The method as claimed in claim 9 wherein the certificate revocation message includes a broadcast sequence indicator, and wherein the client device (140) compare the broadcast sequence indicator of the certificate revocation message with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed.

11 . The method as claimed in claim 10 wherein, upon the client device determining that one or more intervening certificate revocation messages have been missed, the client device requests a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

12. The method as claimed in claim 10 or 11 wherein the broadcast sequence indicator is a numeric indicator that is incremented with each certificate revocation message broadcast, and wherein the client device compares the broadcast sequence indicator with a preceding broadcast sequence indicator by calculating the numeric difference thereof and determining that it had not missed any intervening certificate revocation messages if the difference is equal to the increment value.

13. The method as claimed in any one of claims 9 to 12 wherein the identifier associated with the cryptographic certificate is a serial number of the certificate.

14. The method as claimed in any one of claims 9 to 13 wherein the certificate revocation message is broadcast in a publisher-subscriber (pub/sub) messaging pattern, and wherein a certificate revocation message broadcast is preceded by subscribing (210) to the broadcasts.

15. The method as claimed in any one of claims 9 to 14 wherein the certificate revocation message is digitally signed by the server and wherein the client device updates the list maintained by the client device if able to verify the digital signature of the message.

16. The method as claimed in any one of claims 9 to 15 including performing (220) a cryptographic communication handshake with a remote client device during which a cryptographic certificate associated with the remote client device is received therefrom; checking (222) the list maintained by the client device and terminating (224) communication with the remote client device if the list indicates the cryptographic certificate as no longer being valid.

17. The method as claimed in claim 16 wherein the client device is a Transport Layer Security (TLS) client and for the cryptographic communication handshake to be a TLS handshake.

18. A system for maintaining a cryptographic revocation list at client devices, the system including a server (110) having a memory (304) for storing computer-readable program code and a processor (302) for executing the computer-readable program code, the server comprising: a certificate revocation component (306) for determining that a cryptographic certificate should be revoked; a publishing component (314) for, based on the determination, causing a certificate revocation message to be broadcast to a network of client devices (140); and a message compiling component (308) for including an identifier associated with the cryptographic certificate in the certificate revocation message to broadcast; wherein each client device (140) that receives the certificate revocation message updates a list (144) maintained by the client device, the updated list indicating that the cryptographic certificate (152) identified by the identifier is no longer valid.

19. The system as claimed in claim 18 further including a sequence component (310) for including a broadcast sequence indicator in the certificate revocation message, and wherein each client device (140) that receives the certificate revocation message compares the broadcast sequence indicator with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed; and a request receiving component (316) for, upon a client device determining that one or more intervening certificate revocation messages have been missed, receiving a request from a client device for a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

20. A system for maintaining a cryptographic revocation list at client devices, the system including a client device (140) having a memory (404) for storing computer-readable program code and a processor (402) for executing the computer-readable program code, the client device comprising: a subscribing component (406) for receiving a certificate revocation message broadcast, the certificate revocation message including an identifier associated with a cryptographic certificate; and a list maintaining component (410) for updating a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid, wherein the certificate revocation message is broadcast in response to a server determining that the cryptographic certificate should be revoked.

21 . The system as claimed in claim 20 wherein the certificate revocation message includes a broadcast sequence indicator, and wherein the client device (140) includes a comparator component (412) for comparing the broadcast sequence indicator of the certificate revocation message with a preceding broadcast sequence indicator to determine whether or not any intervening certificate revocation messages have been missed; and wherein the client device includes a requestor component (414) for, upon determining that one or more intervening certificate revocation messages have been missed, requesting a list update which may be a request for the missing intervening certificate revocation messages, alternatively for a full update of all relevant certificate revocation messages.

22. The system as claimed in claim 21 wherein the broadcast sequence indicator is a numeric indicator that is incremented with each certificate revocation message broadcast, and wherein the comparator component (412) is arranged to compare the broadcast sequence indicator with a preceding broadcast sequence indicator by calculating the numeric difference thereof and determining that it had not missed any intervening certificate revocation messages if the difference is equal to the increment value.

23. A computer program product for maintaining a cryptographic revocation list at client devices, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: determining that a cryptographic certificate should be revoked; based on the determination, causing a certificate revocation message to be broadcast to a network of client devices, the certificate revocation message including an identifier associated with the cryptographic certificate; wherein each client device that receives the certificate revocation message updates a list maintained by the client device, the updated list indicating that the cryptographic certificate identified by the identifier is no longer valid.