Signcryption and proof-of-possession for cryptographic key management

Abstract

The present disclosure is directed to a secure storage system—also referred to herein as a vault—that securely stores and manages access to cryptographic keys used by computing devices.

Description

ICUH.794WO PATENT SIGNCRYPTION AND PROOF-OF-POSSESSION FOR CRYPTOGRAPHIC KEY MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATION

[0001] The present application claims priority to India Provisional Patent Application No. 202511030187, filed March 28, 2025 and titled “SIGNCRYPTION AND PROOF-OF-POSSESSION FOR CRYPTOGRAPHIC KEY MANAGEMENT." the contents of each of which are incorporated by reference herein and made part of this specification.TECHNICAL FIELD

[0002] This disclosure relates to the field of medical device management, and particularly to systems and methods for secure communication and data storage in connection with medical devices and related computing systems.BACKGROUND

[0003] Electronic medical devices and related computing systems (e.g., management servers) often work with secure data and secure communications. For example, a processor of a medical device or related computing system may execute cryptographic operations on data to be stored, loaded from storage, and / or transmitted via or received via a network. The cryptographic operations are performed with virtual “keys” (hereinafter, “keys” or “key” if singular), including “secret keys” that are not to be exposed in decrypted form outside of the devices themselves.SUMMARY

[0004] In some aspects, the techniques described herein relate to a system including: computer-readable memory storing a server “public” (non-secret) key; a network interface: and one or more processors in communication with the computer-readable memory and the network interface, wherein the one or more processors are programmed by executable instructions to at least: generate an application encryption key; encrypt application data using the application encryption key to generate encrypted application data; signcrypt the application encryption key using the server public key and a vault public key to generate a signcrypted application encryption key, wherein the vault public key is associated with a vault system (as described more particularly below) configured to securely store keys on behalf of serverdevices; send the signcrypted application encryption key to the vault system via the network interface: and subsequent to removal of the application encryption key from the computer-readable memory': obtain a partially un-signcrypted application encryption key from the vault system; un-signcrypt the partially un-signcrypted application encryption key using a server secret key; and decrypt at least a portion of the encrypted application data using the application encryption key that has been un-signcrypted.

[0005] In some aspects, the techniques described herein relate to a computer-implemented method including: as performed by a server device including one or more processors, a data store, and a network interface, generating a server key pair including a server secret key and a server public key; encrypting the server secret key using a recovery key to generate an encrypted server secret key’; storing the encrypted server secret key in the data store; encrypting the recovery key using a vault public key to generate an encrypted recovery key, wherein the vault public key is associated with a vault system configured to securely store keys on behalf of server devices; generating a set of proof of possession parameters; sending the encrypted recovery key and the set of proof of possession parameters to the vault system via the network interface; and subsequent to a restart of the server device; executing a proof-of-possession protocol with the vault system to obtain recovery key in decry pted form from the vault system; and decrypt the server secret key using the recovery' key.

[0006] In some aspects, the techniques described herein relate to a vault system for maintaining encryption keys of computing devices, including: a data store storing signcrypted encry ption keys, encry pted recovery keys, and proof of possession parameters for each of a plurality' of computing devices; and one or more processors in communication with the data store and configured by executable instructions to at least: execute a signcryption protocol with individual computing devices of the plurality of computing devices, wherein execution of the signcryption protocol with a first computing device of the plurality of computing devices includes: verification of a signcrypted encryption key received from the first computing device prior to storage of the signcrypted encryption key in the data store; and partial un-signcryption of the signcrypted encryption key in response to a request from the first computing device; and execute a proof-of-possession protocol with individual computing devices of the plurality' of computing devices, wherein the proof-of-possession protocol with a second computing device of the plurality' of computing devices includes: generation of a challenge using a set of proof-of-possession parameters associated with the second computing device in response to a request for a recovery key associated with the second computing device; and provision of the recoverykey to the second computing device in response to verifying a response to the challenge using the set of proof-of-possession parameters.

[0007] In some aspects, the techniques described herein relate to a vault system for maintaining encryption keys of computing devices, including: a data store storing signcrypted encryption keys for each of a plurality' of computing devices; and one or more processors in communication with the data store and configured by executable instructions to at least: execute a signcryption protocol with individual computing devices of the plurality of computing devices, wherein execution of the signcryption protocol with a first computing device of the plurality of computing devices includes: verification of a signcrypted encry ption key received from the first computing device prior to storage of the signcrypted encryption key in the data store; and partial un-signcryption of the signcrypted encryption key in response to a request from the first computing device.

[0008] In some aspects, the techniques described herein relate to a vault system for maintaining encryption keys of computing devices, including: a data store storing encry pted recovery keys and proof of possession parameters for each of a plurality of computing devices; and one or more processors in communication with the data store and configured by executable instructions to at least: execute a proof-of-possession protocol with individual computing devices of the plurality of computing devices, wherein the proof-of-possession protocol with a first computing device of the plurality of computing devices includes: generation of a challenge using a set of proof-of-possession parameters associated with the first computing device in response to a request for a recovery^ key associated with the first computing device; and provision of the recovery' key to the first computing device in response to verifying a response to the challenge using the set of proof-of-possession parameters.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments of various inventive features will now be described with reference to the following drawings. Throughout the drawings, reference numbers may be reused to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure.

[0010] FIG. 1 is a block diagram of an example network environment including a vault and various servers and medical devices according to some embodiments.

[0011] FIG. 2 is a block diagram illustrating data flows and interactions between a server and a vault during a registration protocol according to some embodiments.

[0012] FIG. 3 is a block diagram illustrating data flows and interactions between a server and a vault during a signcryption protocol according to some embodiments.

[0013] FIG. 4 is a block diagram illustrating additional data flows and interactions between a server and a vault during a signcryption protocol according to some embodiments.

[0014] FIG. 5 is a block diagram illustrating data flows and interactions between a server and a vault during a proof-of-possession protocol according to some embodiments.

[0015] FIG. 6 is a block diagram of a server and vault, and components thereof, according to some embodiments.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0016] The present disclosure is directed to a secure storage system — also referred to herein as a “vault’’ — that securely stores and manages access to cryptographic keys used by computing devices. Computing devices use the cryptographic keys to, for example, encrypt and decry pt locally stored data, or securely communicate with other devices. The vault implements various protocols to ensure cryptographic keys are stored securely on behalf of multiple respective computing devices and are provided to only the devices that prove possession of certain secrets (e.g., other secret keys, or secrets encrypted with the cryptographic keys maintained by the vault). Advantageously, the protocols of the vault allow computing devices to automatically (e.g., without user interaction) recover their secrets after crashing, restarting, or otherwise entering a state in which neither unencrypted secrets nor cryptographic keys needed to decrypt encrypted secrets are available locally. Moreover, the vault — and protocols implemented by the vault — allow secrets to be recovered automatically and securely without the vault having access to the unencrypted secrets.

[0017] With reference to an illustrative example, a clinic or other health care setting may manage patient data, patient therapies, other data or processes, or the like. A management system, such as an infusion safety system, may include any combination of server-executed applications (e.g., medication safety systems or electronic health record (EHR) managers), medical device-executed applications (e.g., on-device safety software executing on infusion pumps or medication preparation devices), or the like. For example, a web-based medication safety system that manages medication administration across a clinic may include many individual plugins, modules, components, subsystems, or the like (collectively referred to herein as “applications”) that communicate with each other. The applications use secret keys to protect sensitive information, and each application creates, stores, and manages its secret keys. Conventionally this requires dependence on the underlying operating system of thecomputing device on which the application runs. For example, in Microsoft Windows, the creation, storage, and management of secret keys is provided by the Data Protection Application Programming Interface (DP API); in Android, by the Android Keystore; in Linux, by the Linux Key store. The master key is typically encrypted with a user’s password or with another data item that is provided interactively. Therefore, after a crash or other restart event the master key is not able to be recovered automatically (e.g., without user interaction). Moreover, the master secret used in key managers like DP API is different for different machines. Thus, an application is not portable from one machine to another.

[0018] Aspects of the present disclosure address some or all of the issues noted above, among others, using a network-accessible vault that securely stores keys on behalf of multiple computing devices. Accordingly, the keys — and management thereof — are not tied to a specific operating system, or even to a specific device. To ensure that the keys stored at the vault are provided back only to applications or devices from which they were received or which are otherwise permitted to access the keys, the vault implements a signcryption protocol.

[0019] Generally described, signcryption includes two otherwise distinct operations — encryption and cryptographic signing — performed simultaneously in a single operation. In data security, the main objectives are privacy, data integrity and authentication. Privacy may be provided using asymmetric encry ption with public and secret keys. Data integrity and authentication may be provided through cryptographic signatures. Conventionally, the two operations — asymmetric encryption and cryptographic signing — are implemented as two distinct operations in an encrypt-then-sign or sign-then-encrypt protocol. Signcryption satisfies all three security7requirements in a single operation and at a lower cost, in terms of computing resources, than using separate encry ption and signature operations in sequence. Example signcryption schemes include ElGamal-based or pairing-based techniques.

[0020] The signcryption protocol implemented with the vault further improves security by7encr pting the cryptographic key to be stored at the vault using keys of both the source of the cry ptographic key to be stored and the destination at which it is to be stored. More specifically, the signcryption process involves encrypting the cryptographic key to be stored using both a key of an application executing on a device separate from the vault, and a key of the vault itself. When the application requests the signcrypted cryptographic key7back from the vault, the vault provides a partial un-signcryption of the signcry pted cryptographic key. The un-signcryption operation can only be completed using a secret key that corresponds to a public key used to signcrypt the cryptographic key7before storage at the vault. Because the application’s secret key is maintained securely by the application, the un-signcryptedcryptographic key is not exposed outside of the application. As a result, the vault may be implemented remotely from the devices on which applications are executing. For example, the vault may be implemented at a cloud computing provider accessible over the public internet.

[0021] Additional aspects of the present disclosure provide a crash recovery mechanism that uses a proof-of-possession protocol. The proof-of-possession protocol requires the application to prove, to the vault, that the application is in possession of secrets previously encrypted using a cryptographic key being requested from the vault. The cryptographic key stored at the vault in this case may be different from the cryptographic key described herein with respect to the signcryption protocol. The cryptographic key stored and accessed using the signcryption protocol is an application cryptographic key used to encrypt application data stored locally at the device on which the application is executing. In contrast, the cryptographic key that is the subject of the proof-of-possession protocol may be a crash recovery key that is used to encrypt the application’s secret key used in the signcryption protocol to complete the un-signcryption process. If the application, or the machine on which the application is executing, crashes or otherwise restarts, the application’s secret key stored in volatile memory is lost. Therefore, advantageously, an encrypted version of the secret key is stored in persistent local storage to be recovered after the application or machine restarts.

[0022] Some conventional systems encry pt secret keys using a password or other interactively-provided data. When such systems restart after a crash, a user provides the password and the secret key is decrypted and loaded in volatile memory for use. However, because the password or other data is provided interactively, it is not possible to automatically restart and recover after a crash. In contrast, the present disclosure provides for encryption of the secret key using a crash recovery key that is sent to the vault for storage. The encry pted secret key is stored in persistent local storage, while the crash recovery key is removed from memory — volatile or persistent — of the machine on which the application is executing. When the application restarts, the application is able to obtain the crash recovery^ key from the vault and decry pt the encry pted secret key stored in persistent local storage. The secret key is then available for use in the signcryption protocol described herein.

[0023] The vault implements a proof-of-possession protocol to ensure that the crash recovery key is not provided to an application that does not have possession of the secret key encrypted with the crash recovery' key. For example, when the application initially encrypts the secret key, the application may also generate a set of proof-of-possession parameters that are tied to the encrypted secret key. From these proof-of-possession parameters, the vault is able to generate a challenge comprising data that may be properly processed using theencrypted secret key. For example, the vault is configured to expect a response to the challenge, and the response will only be valid if produced by a function that takes the challenge and the encrypted secret key as input. If the response is valid, then the vault is ensured that the application has possession of the encrypted secret key, and the vault provides the crash recovery key to the application. Advantageously, this allows the application to restart, automatically obtain the crash recovery’ key, and decrypt the secret key without user intervention or other activity.

[0024] Various aspects of the disclosure will now be described with regard to certain examples and embodiments, which are intended to illustrate but not limit the disclosure. Although aspects of some embodiments described in the disclosure will focus, for the purpose of illustration, on particular examples of devices, cryptographic algorithms, and the like, the examples are illustrative only and are not intended to be limiting. In some embodiments, the systems and methods described herein may be applied to additional or alternative devices, cryptographic algorithms, etc. Additionally, any feature used in any embodiment described herein may be used in any combination with any other feature or in any other embodiment, without limitation.Network Environment

[0025] FIG. 1 illustrates an example network environment in which vault system (also referred to herein as a vault for brevity) may be implemented to provide secure storage for, and authenticated provision of cryptographic keys to, various devices. In some embodiments, the devices may be part of a clinical management system, such as an infusion safety' system. For example, the devices may be or include any number of servers 110A - 1 ION that execute applications (e g., medication safety systems or EHR managers). As another example, the devices may be or include any number of medical devices 120A - 120N that execute applications (e.g., on-device safety software executing on infusion pumps or medication preparation devices).

[0026] The vault 100 includes various modules and components to provide key storage and management features. In some embodiments, as shown, the vault 100 includes a cryptography subsystem 102 to encrypt and decrypt keys, verify and partially un-signcrypt keys, generate and verify proof-of-possession challenges, and the like. The vault 100 further includes a key and parameter data store 104, also referred to herein as storage 104 for brevity'.

[0027] The vault 100 may be implemented using any of a variety’ of computing systems, such as server computing devices, mainframe computing devices, midrangecomputing devices, or the like. For example, a single host computing device may execute one or more components of the vault 100, such as the cryptography subsystem 102 and / or storage 104. The vault 100 may include any number of such hosts. FIG. 6 illustrates an example computing device that may be used.

[0028] In some embodiments, the features and services provided by the vault 100 are implemented as web services consumable via a communication network. In further embodiments, the vault 100 (or individual components thereof) is provided by one or more virtual machines implemented in a hosted computing environment. The hosted computing environment may include one or more rapidly provisioned and released computing resources, such as computing devices, networking devices, and / or storage devices. A hosted computing environment may also be referred to as a '■cloud" computing environment.

[0029] In some embodiments, with continued reference to FIG. 1, the vault 100 may communicate with the servers 110A-110N and / or medical devices 120A-120N via a communication network 180 (also referred to simply as a “network”). The network 180 may¬ be a publicly-accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In some cases, the network may be or include a private network, personal area network, local area network, wide area network, global area network, cable network, satellite network, cellular data network, etc., or a combination thereof, some or all of which may or may not have access to and / or from the Internet.

[0030] The servers 110A-110N include various modules and components to provide key and data storage and management features. In some embodiments, as shown, a server 110A includes a cryptography subsystem 112 to encrypt and decrypt data, signcrypt and un-signciypt keys used in cryptographic data operations, generate proof-of-possession parameters and respond to proof-of-possession challenges, and the like. The server 110A further includes a key and data store 114, also referred to herein as storage 114 for brevity.

[0031] The servers 110A-110N may be implemented using any of a variety of computing systems, such as server computing devices, mainframe computing devices, midrange computing devices, or the like. For example, a single host computing device may execute one or more components of a server 110A, such as the cryptography subsystem 112 and / or storage 114. The server 110A may include any number of such hosts. FIG. 6 illustrates an example computing device that may be used.

[0032] The medical devices 120A-120N may include any of a variety of computerized medical systems, such as infusion pumps, medication preparation systems, or the like. The medical devices 120A-120N include various modules and components to providekey and data storage and management features. In some embodiments, as shown, a medical device 120A includes a cryptography subsystem 122 to encrypt and decrypt data, signcrypt and un-signcrypt keys used in cryptographic data operations, generate proof-of-possession parameters and respond to proof-of-possession challenges, and the like. The medical device 120A further includes a key and data store 124, also referred to herein as storage 124 for brevity.

[0033] Although the description that follows focuses on the interaction of a server 110 and (and applications executing thereon) and the vault 100, the examples are provided for purposes of illustration only. In some embodiments, a medical device 120 or another computing device may perform any of the interactions and protocols described with respect to a sen7er 110.Registration Protocol

[0034] FIG. 2 illustrates data flows and interactions between a vault 100 and a server 110 during a registration protocol. In the registration protocol, the server 110 is initialized with various encryption keys. The server 110 provides a crash recoven key to the vault 100 for storage. The data flows and interactions are numbered sequentially to facilitate discussion of the protocol; however, the sequential numbering is provided for purposes of example only and is not intended to be limiting or required. In some embodiments, certain data flows and interactions may be performed in a different order, performed in parallel, or omitted.

[0035] The example computations that follow have been simplified for purposes of illustration. In some embodiments, all group operations are computed “mod / ?’' and all field operations — such as field multiplication, field addition and modular inverse — are performed “mod q ” where p and q are Digital Signature Algorithm (DSA) parameters as described herein.

[0036] As shown, the server 110 receives a vault public key 200 (abbreviated PKv) at [1], The vault public key 200 is provided to or generated by the vault 100 in a vault initialization procedure (not shown). For example, an engineer or administrator may provision the vault 100 with a vault key pair for asymmetric cryptography. The vault key pair, including vault public key 200 and vault secret key 202 (abbreviated SKv), may be generated using any suitable key generation algorithm. For example, the vault public key 200 and vault secret key 202 may be DSA keys with a length of 2048-bits. The public DSA parameters include the primes p, q along with a generator g. According to DSA, if vault secret key 202 is set to b l, then vault public key 200 is g''b 1 (or: the result of generator g raised to the power of the vault secret key b l). The keys and parameters are stored for future operations.

[0037] The vault public key 200 and public DSA parameters may be provided to the server 110 by an engineer or administrator initiating the registration protocol (e.g.. by typing the vault public key 200, loading the vault public key 200 PKv and public DSA parameters from a storage device, or the like). In some embodiments, the vault 100 provides the vault public key 200 and public DSA parameters to the server 110 over network 180.

[0038] At [2] the server 110 generates a server key pair, including a server public key 210 (abbreviated PKs) and a server secret key (abbreviated SKs). The server’s cryptography subsystem 112 may generate the server key pair using any suitable key generation algorithm, such as DSA. For example, the cryptography subsystem 112 may generate server key pairs <a, g^{a}> and <b_2, gr'{b_2}>, where a and b_2 are DSA keys of length 2048. In this example, the server secret key is <a, b_2>.

[0039] At [3], the server 110 generates a crash recovery key and uses it to encrypt the server secret key, generating an encrypted server secret key 212. The crash recovery key may be any suitable key for encrypting data. In some embodiments, the cry ptography¬ subsystem 112 may use a pseudo random number generator (PRNG) or other randomizing algorithm to generate a random nonce, which serves as the crash recovery key. The cryptography subsystem 112 may encrypt the server secret key using the random nonce and an encry ption algorithm such as Advanced Encry ption Standard (AES).

[0040] At [4], the server generates proof-of-possession parameters 240 (abbreviated POPP) for use in a crash recovery protocol, as described elsewhere herein. The proof-of-possession parameters 240 are values computed from the data for which possession is to be proven — in this case, the server secret keys that have been encrypted using the crash recovery key. For example, the vault 100 may use the proof-of-possession parameters 240 to generate a challenge (e.g.. other values calculated from the proof-of-possession parameters). Due to the mathematical relationships between the proof-of-possession parameters 240 and the encry pted server secret key(s) 212, a valid response to the challenge may7only be generated using the encrypted server secret key(s) 212 stored on the server 110. In this way, the server 110 proves possession of the encrypted server secret key(s) 212 without having access the server secret key(s) in unencrypted form and without providing the server secret key(s) — in either encrypted or unencrypted form — to the vault 100.

[0041] Table 1 below provides an example algorithm that the server’s cryptography subsy stem 112 may use to generate proof-of-possession parameters 240 from the encrypted server secret key(s) 212. Note that Phi(...) indicates use of the Phi (<b) function, also knownas Euler's Totient function. Note also that Prod(... ) indicates calculation of the product of the parameters of the function.• Let M = the encrypted server secret keys = <w_l, / w_2. ..., m_n>• Choose two safe primes p and q and compute N=p*q• Choose e and d such that the product ed is congruent to 1 mod Phi(JV)• Choose n random generators from Z _nA* <g_l, g_2, ..., g_n>• Compute E l = <g_lAd, g_2^d, gji^d> mod N• Set E_2 = <e, N>• Compute Sigma = Prod(g_zA{m_z})A<7 mod N [For i = 1 to n]• Set Proof-of-Possession Parameters = <E_1, E_2, Sigma>Table 1 - Proof-of-Possession Parameter Generation

[0042] At [5], the server 110 stores the vault public key 200. server public key 210, and encrypted server secret key 212 in storage 114 (e.g., on a solid state drive, on a hard disk drive, in persistent flash memory, or the like).

[0043] At [6], the server’s cryptography subsystem 112 uses the vault public key 200 to encrypt the crash recovery7key, generating an encrypted crash recovery key 230 (abbreviated ECRK).

[0044] At [7], the server 110 sends the encrypted crash recovery key 230, the server public key 210, and the proof-of-possession parameters 240 to the vault 100.

[0045] At [8], the vault 100 stores the encrypted crash recovery key 230, the server public key 210, and the proof-of-possession parameters 240 to storage 104 (e.g., on a solid state drive, on a hard disk drive, in persistent flash memory, or the like).Application Encryption Key Signcryption Protocol

[0046] During the course of operation, the server 110 may generate or access data to be stored locally. If the data is of a sensitive nature or is otherwise to be secured, the cryptography subsystem 112 can encrypt the data prior to storing it in storage 114. One method of encrypting data is to use a symmetric cryptographic key that both encrypts and decrypts the data. For example, the cryptography subsystem 112 may use the AES encryption algorithm and an application encryption key to secure the data. To secure the application encryption key, the server 110 may store an encrypted version of the application encryption key at the vault 100 and request it from the vault 100 when needed. Thus, the application encryption key is not-lipresent on the server 110 in unencry pted form except when being used by the cry ptography subsystem 112 to encrypt or decry pt application data; during such use, it is stored in volatile memory only. The application encryption key is not stored on the server 110 in persistent storage even in encry pted form. Moreover, because the application encryption key is sent to — and stored at — the vault 100 in encry pted form, it is not exposed outside the server 110 in unencrypted form. One method for ensuring the application encryption key remains secure, untampered with, and available only to authenticated entities is to use signcryption.

[0047] FIG. 3 illustrates an example signcryption protocol for storing an application encry ption key (abbreviated AEK) at the vault 100 and obtaining the application encryption key from the vault 100. At [A], the cryptography subsystem 112 generates the application encryption key. For example, if the cryptography subsystem 112 is using the AES-256 algorithm, then the size of the application encryption key is 256 bits.

[0048] At [B], the cryptography subsystem 112 signcrypts the application encryption key. To signcrypt the application encry ption key, the cry ptography subsystem 112 uses keys associated with both the server 110 and the vault 100. For example, the cryptography subsystem 112 may encrypt the application encryption key using both the server secret key and the vault public key.

[0049] Table 2 below provides an example algorithm that the server's cryptography subsystem 112 may use to signcrypt the application encryption key to produce a signcrypted application encry ption key 250 (abbreviated SCAEK). Note that “hash(... )’?indicates use of an appropriate hash function, such as Secure Hash Algorithm 256-bit (SHA-256). Note also that “concat(... )” indicates concatenation of the parameters passed to the function.• Choose random values x, z (e g., 32 bit values generated using a PRNG)• Compute the following:o k= (gA{6 jAx) mod po kl = (gA{d_l)Ax)o £2 = (gA{x})o k3 = (g^{z})o K = hash(A. k\ , £2, k3)o cl = AES Enc (AEK 11 K, K)o r = hash(concat(cJ, gA{a}, gA{6}, kl. k3))o s = a + r * zSCAEK = <cl, &2, r, s>Table 2 - Signcryption of Application Encry ption Key

[0050] At [C], the server 110 sends the signcry pted application encryption key 250 to the vault 100 for storage.

[0051] At [D], the vault’s cryptography subsystem 102 verifies the signcrypted application encryption key 250. For example, the cryptography subsystem 102 verifies whether the signature of the signcrypted application encryption key 250 has been validly applied by the server 110.

[0052] Table 3 below provides an example algorithm that the vault's cryptography subsystem 102 may use to verify the signcryption of the signcrypted application encryption key 250.• Compute d = gA{.$•}• Compute e = gA{n} (Note: gA{a} is the server public key)• Compute (gA{z}) = (J / e)A{rA{-l} }• Check if r = hash(concat(cl, gA{a}, gA{Z?}, &2,(g)A{z}))• If above check is true, the signcry pted application key is verified as valid;otherwise, the signcrypted application key is rejectedTable 3 - Verification of Signcrypted Application Encryption Key

[0053] At [E], if the signcrypted application encryption key 250 has been verified, the vault 100 stores the signcrypted application encryption key 250 in storage 104.

[0054] At [F], the server 110 encry pts application data using the application encryption key to generate encrypted application data 260, and stores the encry pted application data 260 in storage 114 (e.g., on a solid state drive, on a hard disk drive, in persistent flash memory, or the like). In another example, the server decrypts encrypted application data 260 using the application encry ption key.

[0055] At [G], the unencrypted application encry ption key is removed from volatile storage (e.g., the unencrypted application key stored in a portion of memory reserved for the cryptography subsystem 112 is overwritten or otherwise rendered unrecoverable).

[0056] In some embodiments, data flows and interactions described above as occurring sequentially may be performed in parallel or otherwise asynchronously , or in a different order. For example, the server 110 may begin encrypting or decrypting application data using the application encryption key prior to, or in parallel with, signcrypting of the application key or sending the signcrypted application key 250 to the vault 100.

[0057] After storage of the signcrypted application encryption key at the vault 100 and removal of the unencrypted application encryption key from memory’, the server 110 may determine to request the signcrypted application encryption key from the vault 100. For example, during the course of operation the server 110 may determine that encrypted application data 260 is to be accessed from storage 114 and decry pted for use. As another example, the server 110 may determine that additional application data is to be encrypted and stored in storage 114.

[0058] FIG. 4 illustrates a signcrypted application encryption key retrieval protocol that the server 110 and vault 100 may execute to provide the server 110 with the signcrypted application encryption key previously stored at the vault 100. Because the signcrypted application encryption key 250 has been previously stored at the vault (e.g., as shown in FIG.3), the data flows and interactions in FIG. 4 are labeled to continue sequentially from [G] of FIG. 3, when the unencrypted application encryption key was removed from memory of the server 110.

[0059] At [H], the server 110 can request the application encryption key from the vault. At [I], the vault’s cryptography subsystem 102 loads the signcrypted application encryption key from storage 104. At [J], the cryptography’ subsystem 102 partially unsigncrypts the signcry pted application encryption key 250 using the vault secret key 202 to generate the partially un-signcrypted application encry ption key 252 (abbreviated PUSCAEK).

[0060] Table 4 below provides an example algorithm that the vault’s cryptography subsystem 102 may use to generate the partially un-signcrypted application encryption key 252.• Compute (gA{x})A{6_l} = C_2A{6_1 }• PUSCAEK = < cl, £2, r, s, (gA{x})A{Z?_l }>Table 4 - Partial Un-signcryption of Application Encryption Key (PUSCAEK)

[0061] At [K], the vault 100 sends the partially un-signcrypted application encry ption key 252 to the server 110.

[0062] At [L], the server’s cryptography subsystem 112 fully un-signcrypts the partially un-signcrypted application encryption key 252 to obtain the application encryption key.

[0063] Table 5 below provides an example algorithm that the server’s cryptography subsystem 112 may use to obtain the fully un-signcrypted application encry ption key.• Compute d = (gA{5 } )• Compute e = (gA{<?})• Compute (gA{z}) = (<f / <?)A{rA{-l}}}• Compute k = (gA{x}A{d_l})A{6_2]• Compute K = hash(U gA{xA{6_l}, k2, g*{z})• Compute AEK | | K = AES_Dec(cl, K)• Compute r' = hash(concat(cl. gA{a}, gA{6}, kZ, gA{z}))• Check r = = r' and K = = K'• If the above check is true, AEK is accepted as the application encryption keyTable 5 - Completing Un-signcryption of Application Encryption Key

[0064] At [M], the cryptography subsystem 112 loads encrypted application data 260 from the storage 114, and at [N] the cry ptography subsystem 112 decrypts the encrypted application data 260 using the application encryption key. Additionally, or alternatively, the cryptography subsystem 112 may encrypt newly received or generated application data, and store the encr pted application data 260 in storage 114.

[0065] After using the application encry ption key to decry pt encry pted application data 260 or to generate additional encrypted application data 260, the application encryption key may be removed from volatile memory of the server 110.Restart / Crash Recovery Protocol with Proof-of-Possession

[0066] As discussed herein, the server 110 maintains an encrypted server secret key 212 in persistent storage. In some embodiments, the unencrypted server secret key’ is maintained only in volatile storage. The key that was used to encrypt the encrypted server secret key 212 — the crash recovery’ key — is not maintained at the server in either volatile or persistent storage. If the sen' er 110 crashes or otherwise restarts, the data in volatile storage — including the unencrypted server secret key — is lost. To recover in this scenario, the server 110 is to first obtain the crash recovery key from the vault 100, and decrypt the encr pted server secret key 212 stored in storage 114. Before obtaining the crash recovery key’ from the vault 100, the server 110 and vault 100 execute a proof-of-possession protocol in which the server 110 proves to the vault 100 that the server 110 is in possession of the encrypted server secret key 212 for which the crash recovery key is being requested.

[0067] As shown in FIG. 5, at [i] the server 110 requests the crash recovery' key from the vault 100. The request may be sent automatically (e.g., without user interaction) after the server 110 begins operation.

[0068] At [ii], the vault’s cryptography subsystem 102 loads proof-of-possession parameters 240 from storage 104. The proof-of-possession parameters 240 are values, previously generated by the server 110 using the encrypted server secret key 212, from which challenges may be generated to determine whether an entity has access to the encrypted server secret key 212.

[0069] At [iii], the cryptography subsystem 102 generates a challenge using the proof-of-possession parameters 240.

[0070] Table 6 below provides an example algorithm that the vault’s cryptography subsystem 102 may use to generate a proof-of-possession challenge to which the server 110 is to respond before the vault 100 provides the crash recovery key.• Choose a random number r (|r| = 128-Bytes)• Compute the challenge <Chall> = <E_l>Ar mod No This is the exponentiation of each element in the vector E l with the random value r with respect to modulo NTable 6 - Generating Proof-of-Possession Challenge

[0071] At [iv], the vault 100 sends the challenge to the server 110. At [v], the server’s cryptography subsystem 112 loads the encrypted server secret key 212 from storage, and at [vi] the cryptography subsystem 112 generates a response to the challenge using the encry pted server secret key 212. The response is one or more values calculated using both the challenge from the vault 100, and the encrypted server secret key 212 stored on the server 110.

[0072] Table 7 below provides an example algorithm that the server's cryptography subsystem 112 may use to generate a response to the challenge from the vault 100.• Compute <clientChall> = <Chall_zA{ / w_z} mod N> [For i = 1 to n\• Compute the response Resp = Prod(clientChall) mod NTable 7 - Generating Response to Proof-of-Possession Challenge

[0073] At [vii], the server 110 sends the challenge response to the vault 100. The vault verifies the challenge response at [viii] using the proof of possession parameters. In some embodiments, the verification involves computing a first value or set of values from theresponse, and a second value or set of values from the proof-of-possession parameters. If the two sets of values match, then the server 110 has proved (to a statistically high degree of certainty) that the server 110 is in possession of the encrypted server secret key 212 that was used to generate the proof-of-possession parameters, and is therefore the key that was encrypted using the crash recovery' key currently being requested.

[0074] Table 8 below provides an example algorithm that the vault's cryptography subsystem 102 may use to verify the challenge response from the server 110.• W = Resp• Compute X = W'e mod N• Y = SigmaA{re} mod N• Check if X= Y1• If the above check is true, possession of encry pted keys has been provedTable 8 - Verifying Response to Proof-of-Possession Challenge

[0075] If the server’s response is verified, the vault 100 proceeds with providing the crash recovery key. At [ix], the vault’s cryptography subsystem 102 obtains the encrypted crash recovery key 230 from storage 104. At [x], the cryptography subsystem 102 decrypts the crash recovery key 232. At [xi], the vault provides the crash recovery key 232 to the server 110.

[0076] At [xii], the server's cryptography subsystem 112 decrypts the encrypted server secret key 212 to obtain the server secret key. The server secret key may then be maintained in volatile memory, and the cryptography subsystem 112 may use the server secret key for various cryptographic operations (e.g., signcryption and un-signcryption).Example Computing Devices

[0077] FIG. 6 illustrates an example vault computing device 600 on which a vault 100 may be implemented in some embodiments. The vault computing device 600 may include: one or more computer processors 602, such as physical central processing units (CPUs) or graphics processing units (GPUs); one or more network interfaces 604, such as network interface cards (NICs); one or more computer readable medium drives 606, such as hard disk drives (HDDs), solid state drives (SSDs), flash drives, and / or other persistent non-transitory computer-readable media; and one or more computer readable memories 610, such as random access memory (RAM) and / or other volatile non-transitory computer-readable media. Thestorage 104 may be implemented on the computer readable medium drive 606. The network interface 604 can provide connectivity to one or more networks or computing devices. The computer processor 602 can receive information and instructions from other computing devices or services via the network interface 604. The network interface 604 can also store data directly to the computer-readable memory 610. The computer processor 602 can communicate to and from the computer-readable memory 610, execute instructions and process data in the computer-readable memory 610, etc.

[0078] The computer-readable memory 610 may include computer program instructions that the computer processor 602 executes in order to implement one or more embodiments. The computer-readable memory' 610 can store an operating system 612 that provides computer program instructions for use by the computer processor 602 in the general administration and operation of the vault computing device 600. The computer-readable memory 610 can also include cryptography subsystem instructions 614 for implementing the features of the cry ptography subsystem 102.

[0079] FIG. 6 also illustrates an example server computing device 650 on which a server 110 may be implemented in some embodiments. The server computing device 650 may include: one or more computer processors 652, such as CPUs or GPUs; one or more network interfaces 654, such as NICs; one or more computer readable medium drives 656, such as HDDs, SSDs, flash drives, and / or other persistent non-transitory computer-readable media; and one or more computer readable memories 660. such as RAM and / or other volatile non-transitory' computer-readable media. The storage 114 may be implemented on the computer readable medium drive 656. The network interface 654 can provide connectivity7to one or more networks or computing devices. The computer processor 652 can receive information and instructions from other computing devices or services via the network interface 654. The network interface 654 can also store data directly to the computer-readable memory 660. The computer processor 652 can communicate to and from the computer-readable memory7660, execute instructions and process data in the computer-readable memory 660, etc.

[0080] The computer-readable memory 660 may include computer program instructions that the computer processor 652 executes in order to implement one or more embodiments. The computer-readable memory 660 can store an operating system 662 that provides computer program instructions for use by the computer processor 652 in the general administration and operation of the server computing device 650. The computer-readable memory 660 can also include cryptography subsystem instructions 664 for implementing the features of the cryptography subsystem 112.Terminology and Additional Considerations

[0081] All of the methods and tasks described herein may be performed and automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or device (e.g., solid state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions, or may be implemented in application-specific circuitry (e.g.. ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid-state memory chips or magnetic disks, into a different state. In some embodiments, the computer system may be a cloud-based computing system whose processing resources are shared by multiple distinct entities or other users.

[0082] Although not explicitly illustrated in the drawings, it is to be appreciated and understood that the subject matter of the present disclosure, described by example or otherwise contemplated herein, could be advantageous in providing or enhancing cybersecurity of medical device systems in accordance with the US Food and Drug Administration (FDA). S ee, e. g. , h ttp^ / ww. fda.gov / medi cal -devices / digital-heal th-center-exceil ence / cv bersecurity .

[0083] Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, operations or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

[0084] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or combinations of electronic hardware and computer software. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware, or as software that runs on hardware, depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[0085] Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality7of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. For example, some or all of the algorithms described herein may' be implemented in analog circuitry' or mixed analog and digital circuitry'. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

[0086] The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory7, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integralto the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.

[0087] Conditional language used herein, such as, among others, "can," "could," "might," "may," “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or steps. Thus, such conditional language is not generally intended to imply that features, elements and / or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and / or steps are included or are to be performed in any particular embodiment. The terms ‘'comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

[0088] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

[0089] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as ■‘a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to cany7out the stated recitations. For example, “a processor configured to cany out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

[0090] While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of thefeatures and benefits set forth herein, as some features can be used or practiced separately from others. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. CLAIMSWHAT IS CLAIMED IS:

1. A system comprising:computer-readable memory storing a server public key;a network interface; andone or more processors in communication with the computer-readable memory and the network interface, wherein the one or more processors are programmed by executable instructions to at least:generate an application encryption key;encrypt application data using the application encryption key to generate encrypted application data;signcr pt the application encryption key using the server public key and a vault public key to generate a signcrypted application encryption key, wherein the vault public key is associated with a vault system configured to securely store keys on behalf of server devices;send the signcrypted application encryption key to the vault system via the netw ork interface; andsubsequent to removal of the application encryption key from the computer-readable memory:obtain a partially un-signcrypted application encryption key from the vault system;un-signcrypt the partially un-signcrypted application encryption key using a server secret key; anddecrypt at least a portion of the encrypted application data using the application encryption key that has been un-signcrypted.

2. The system of claim 1, wherein the one or more processors are programmed by further executable instructions to at least:encrypt the server secret key using a recovery key to generate an encrypted server secret key;store the encrypted server secret key;encrypt the recovery key using a vault public key to generate an encrypted recovery key, wherein the vault public key is associated with a vault system configured to securely store keys on behalf of server devices;generate a set of proof of possession parameters; andsend the encrypted recovery key and the set of proof of possession parameters to the vault system via the network interface.

3. The system of claim 1, wherein the one or more processors are programmed by further executable instructions to at least:subsequent to a restart of the system, execute a proof-of-possession protocol with the vault system to obtain recovery key in decrypted form from the vault system; anddecrypt the server secret key using the recovery key.

4. The system of claim 3, wherein to execute the proof-of-possession protocol, the one or more processors are programmed by further executable instructions to:send a request to the vault system for the recovery7key;receive, from the vault system in response to the request, a challenge; generate a response to the challenge using an encrypted server secret key; and send the response to the vault system.

5. A computer-implemented method comprising:as performed by a server device comprising one or more processors, a data store, and a network interface,generating a server key pair comprising a server secret key and a server public key;encrypting the server secret key using a recovery7key to generate an encrypted server secret key;storing the encrypted server secret key in the data store; encrypting the recovery7key using a vault public key to generate an encrypted recovery key, wherein the vault public key is associated with a vault system configured to securely store keys on behalf of server devices;generating a set of proof of possession parameters;sending the encrypted recover}7key and the set of proof of possession parameters to the vault system via the network interface; andsubsequent to a restart of the server device;executing a proof-of-possession protocol with the vault system to obtain recover}' key in decrypted form from the vault system; and decrypt the server secret key using the recovery key.

6. The computer-implemented method of claim 5, wherein executing the proof-of-possession protocol comprises:sending a request to the vault system for the recovery key;receiving, from the vault system in response to the request, a challenge; generating a response to the challenge using the encrypted server secret key; andsending the response to the vault system.

7. The computer-implemented method of claim 5, further comprising using the server secret key to establish a secure communication channel with the vault system.

8. The computer-implemented method of claim 5, further comprising:generating an application encryption key;using the application encryption key to encrypt and decrypt application data stored in the data store;signcrypting the application encryption key using the server secret key and the vault public key to generate a signcrypted application encryption key;sending the signcrypted application encryption key to the vault system; and removing the application encryption key from volatile memory of the server device.

9. A vault system for maintaining encryption keys of computing devices, comprising:a data store storing signcrypted encryption keys, encrypted recovery keys, and proof of possession parameters for each of a plurality of computing devices; and one or more processors in communication with the data store and configured by executable instructions to at least:execute a signcryption protocol with individual computing devices of the plurality of computing devices, wherein execution of the signcryptionprotocol with a first computing device of the plurality of computing devices comprises:verification of a signcrypted encryption key received from the first computing device prior to storage of the signcrypted encryption key in the data store; andpartial un-signcryption of the signcrypted encryption key in response to a request from the first computing device; and execute a proof-of-possession protocol with individual computing devices of the plurality of computing devices, wherein the proof-of-possession protocol with a second computing device of the plurality of computing devices comprises:generation of a challenge using a set of proof-of-possession parameters associated with the second computing device in response to a request for a recovery key associated with the second computing device; andprovision of the recovery key to the second computing device in response to verifying a response to the challenge using the set of proof- of-possession parameters.

10. The vault system of claim 9, wherein at least one of the first computing device or the second computing device comprises a server.

11. The vault system of claim 9, wherein at least one of the first computing device or the second computing device comprises a medical device.

12. The vault system of claim 9, where execution of the signcryption protocol with a third computing device of the plurality of computing devices comprises:failure to verify a second signcrypted encryption key received from the third computing device; andrejection of the second signcrypted encryption key.

13. The vault system of claim 9, where execution of the proof-of-possession protocol with a third computing device of the plurality of computing devices comprises:generation of a second challenge using a second set of proof-of-possession parameters associated with the third computing device in response to a second request for a second recover}' key associated with the third computing device; and failure to verify a second response to the challenge using the proof-of- possession protocol, wherein the second request for the second recovery key is rejected based on the failure to verify the second response.

14. A vault system for maintaining encryption keys of computing devices, comprising:a data store storing signcrypted encryption keys for each of a plurality of computing devices; andone or more processors in communication with the data store and configured by executable instructions to at least:execute a signcryption protocol with individual computing devices of the plurality of computing devices, wherein execution of the signcryption protocol with a first computing device of the plurality of computing devices comprises:verification of a signcrypted encryption key received from the first computing device prior to storage of the signcrypted encryption key in the data store; andpartial un-signcryption of the signcrypted encryption key in response to a request from the first computing device.

15. The vault system of claim 14, wherein the first computing device comprises a server.

16. The vault system of claim 14, wherein the first computing device comprises a medical device.

17. The vault system of claim 14, where executing of the signcryption protocol with a third computing device of the plurality of computing devices comprises:failure to verify a second signcrypted encryption key received from the third computing device; andrejection of the second signcrypted encryption key.

18. A vault system for maintaining encryption keys of computing devices, comprising:a data store storing encrypted recovery keys and proof of possession parameters for each of a plurality of computing devices; andone or more processors in communication with the data store and configured by executable instructions to at least:execute a proof-of-possession protocol with individual computing devices of the plurality of computing devices, wherein the proof-of-possession protocol with a first computing device of the plurality of computing devices comprises:generation of a challenge using a set of proof-of-possession parameters associated with the first computing device in response to a request for a recovery key associated with the first computing device; andprovision of the recovery key to the first computing device in response to verifying a response to the challenge using the set of proof- of-possession parameters.

19. The vault system of claim 18, wherein the first computing device comprises a server.

20. The vault system of claim 18, wherein the first computing device comprises a medical device.

21. The vault system of claim 18, where execution of the proof-of-possession protocol with a third computing device of the plurality of computing devices comprises:generation of a second challenge using a second set of proof-of-possession parameters associated with the third computing device in response to a second request for a second recovery key associated with the third computing device; and failure to verity7a second response to the challenge using the proof-of- possession protocol, wherein the second request for the second recovery key is rejected based on the failure to verify the second response.

Images