Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
  • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Definitions

• 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.
• 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 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.
• VPN virtual private network
• VoIP voice over IP
• the TLS protocol 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.
• the one node e.g. the client to continue the aforementioned example
• 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.
• 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.
• 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.
• 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.
• OCSP stapling 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.
• 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.
• both parties will again require access to the OCSP server which at least partly defeats the purpose of OCSP stapling.
• a computer-implemented method for maintaining cryptographic revocation lists at client devices 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.
• 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.
• CA certificate authority
• 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.
• a computer-implemented method for maintaining a cryptographic revocation list at client devices 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.
• 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 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. Receiving a certificate revocation message broadcast may be preceded by subscribing to the broadcasts.
• Pub/sub publisher-subscriber
• 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.
• a system for maintaining a cryptographic revocation list at client devices 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.
• a system for maintaining a cryptographic revocation list at client devices 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.
• 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.
• 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.
• 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.
• 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
• Figure 5 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.
• 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.
• 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).
• 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 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.
• a client device 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.
• FIG 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.
• 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.
• TLS Transport Layer Security
• 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).
• the client devices 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).
• 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)).
• both the TLS server and client certificates’ authenticity need to be verified.
• 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.
• 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.
• FIG. 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.
• client device A 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).
• 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.
• client device A (140) updates its list (144) with the sent (217) by the CA (110).
• client device A (140), as a TLS client, attempts to establish a TLS communication session with client device B (150), as a TLS server.
• client device B 150
• 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.
• the steps of the method (100) will be performed with the necessary changes.
• the CA (110) instructs (206) the publication server (120) the CA would issue the instruction to this publication server subcomponent.
• FIG. 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
• CA certificate authority
• 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.
• 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.
• 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.
• FIG 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.
• client device 140
• Figure 4 illustrates exemplary components which may be provided by a client device (140) in a system for maintaining cryptographic certificate revocation lists at client devices.
• client device A 140
• 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.
• 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)).
• 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.
• TLS client confirms the validity of the TLS server; and vice versa.
• FIG. 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.
• a mobile phone e.g. cellular telephone
• satellite phone e.g. cellular telephone
• 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.
• a number of processors may be provided and may be arranged to carry out calculations simultaneously.
• 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).
• ROM read only memory
• RAM random access memory
• BIOS basic input/output system
• 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.
• 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
• 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-FiTM), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuity.
• wireless communication channels e.g., a cellular telephone network, wireless local area network (e.g. using Wi-FiTM), satellite-phone network
• 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
• input/output (I/O) devices such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like
• I/O controller such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like
• 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).
• 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, JavaTM, C++, or PerlTM 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.
• 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.
• RAM random access memory
• ROM read-only memory
• magnetic medium such as a hard-drive
• optical medium such as a CD-ROM.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• Bioethics (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Computer And Data Communications (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=76375371

Family Applications (1)

Country Status (3)

Family Cites Families (4)

• 2021
  • 2021-06-03 WO PCT/IB2021/054884 patent/WO2021245600A1/en unknown
  • 2021-06-03 EP EP21731593.6A patent/EP4162381A1/de active Pending
• 2022
  • 2022-12-14 ZA ZA2022/13535A patent/ZA202213535B/en unknown

Also Published As

Similar Documents

Legal Events