US20170126412A1 - Server systems for distributed cryptographic protocols - Google Patents
Server systems for distributed cryptographic protocols Download PDFInfo
- Publication number
- US20170126412A1 US20170126412A1 US14/928,813 US201514928813A US2017126412A1 US 20170126412 A1 US20170126412 A1 US 20170126412A1 US 201514928813 A US201514928813 A US 201514928813A US 2017126412 A1 US2017126412 A1 US 2017126412A1
- Authority
- US
- United States
- Prior art keywords
- server
- machine
- new
- key
- state information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- 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/3247—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 digital signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- 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/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
-
- 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/40—Specific encoding of data in memory or cache
- G06F2212/402—Encrypted data
Definitions
- the present invention relates generally to server systems for implementing distributed cryptographic protocols, and more specifically to server systems providing proactive security in such protocols.
- Protecting information is essential in the digital economy.
- a common way to protect data is to use cryptographic protocols to process the data in some way, but it is then necessary to protect the state information for such protocols.
- This state information comprises the secret values, such as cryptographic keys, used by servers which implement the cryptographic algorithms.
- cryptographic protocols may be implemented in a distributed fashion. In distributed protocols, a plurality of servers communicate via a network to collectively implement the protocol. This enhances security because protocol operation requires cooperation of more than one server, so more than one server must be hacked for the protocol to be subverted. It is common practice, for example, to distribute (secret share) cryptographic keys between a plurality of servers which can perform operations with the shared key in a distributed fashion to collectively implement some protocol.
- Cryptography offers a rich body of distributed protocols including secret sharing schemes, signature schemes and encryption schemes, as well as more advanced protocols such as threshold password-authenticated secret sharing schemes.
- Resistance against server compromise is one thing, but knowing how to recover from such an event is another.
- recovery from compromise is known as proactive security, or security against transient corruptions.
- Known schemes with proactive security allow a secret key to be refreshed by periodically re-sharing the key among the servers.
- the servers engage in an interactive refresh protocol to re-compute their key-shares for each new time period in operation of the distributed protocol.
- server system for operation as one of multiple such server systems, connectable via a network, to implement a distributed cryptographic protocol.
- the server system includes a machine management server which is operable to provide a plurality of virtual machines.
- the machine management server includes a current virtual machine which is adapted to implement the protocol using a set of communication keys, for communications with other said server systems via the network, and state information for the protocol.
- the server system further comprises a memory, operatively associated with the machine management server, for storing the state information, and a refresh server which is adapted for secure communications with the machine management server.
- the server system is configured, for each of successive new time periods in operation of the protocol, to perform a refresh operation in which: the refresh server retrieves the state information from the memory, generates a new set of communication keys, and sends the state information and new set of keys to the machine management server; the machine management server configures a new virtual machine for implementing the protocol, whereby the new virtual machine receives the new set of keys and state information sent by the refresh server; and the new virtual machine assumes operation as the current virtual machine for the new time period and stores state information for that time period in the memory.
- FIG. 1 is a schematic representation of a distributed system including server systems embodying the invention
- FIG. 2 is a generalized schematic of a computer in a server system of FIG. 1 ;
- FIG. 3 indicates steps performed in a refresh operation of a server system of FIG. 1 ;
- FIG. 4 is a schematic representation of an embodiment of the server system.
- FIG. 5 indicates steps performed in a refresh operation of the FIG. 4 system.
- FIG. 1 is a schematic block diagram of a distributed processing system 1 comprising a plurality n of servers systems 2 embodying the invention.
- the server systems are denoted by S i (1 ⁇ i ⁇ n), where in general n ⁇ 2, and preferably n>2.
- higher values of n offer greater security against offline attack through server compromise.
- the value of n can thus be selected according to security requirements for a given system.
- the server systems S 1 , . . . , S n are connectable via a network 3 (which may in general comprise one or more component networks and/or internetworks, including the Internet) to implement a distributed cryptographic protocol.
- the cryptographic protocol may, for instance, comprise a secret sharing scheme, a signature scheme, an encryption scheme, or a password-authentication scheme. However, the particular functionality of the cryptographic protocol is orthogonal to the system operation to be described.
- Each server system 2 comprises a refresh server 4 and a machine management server 5 as illustrated for server system Si in the figure (the additional server systems S i , i>1, being shown in abstracted form for simplicity).
- the refresh server 4 of system S i is denoted by RS i .
- MS i denotes the machine management server 5 of system S i .
- Each machine management server MS i is operable to provide a plurality of virtual machines, and includes a current virtual machine 6 , denoted by M i .
- the current virtual machine M i is adapted to implement the cryptographic protocol in communication with the current virtual machines M j , j ⁇ i, of other server systems 2 via network 3 .
- each current machine M i uses a set of cryptographic communication keys, denoted by ⁇ ck ⁇ i , for communications with other server systems 2 , and state information st i for the protocol.
- the key-set ⁇ ck ⁇ i may in general comprise one or more communication keys which are used to process messages communicated between servers, e.g. for message encryption and/or authentication purposes, and typically comprises at least one public/private key pair in accordance with a PKI (Public Key Infrastructure) system.
- PKI Public Key Infrastructure
- the state information st i generally comprises one or more values which are used by current machine M i when running the protocol, and typically includes multiple values which may relate to the local machine state and/or the overall protocol state. Such values typically include at least one secret cryptographic key or key-share (secret to one or more machines M i ) which is required for correct operation of the protocol.
- This state information st i is stored, in one or more embodiments, in a WORM (write once read many) memory which is operatively associated with machine management server. State information st i can thus be written to WORM memory 7 by current machine M i , and can be accessed as required via the MS i , but is protected against over-writing in the memory. While not explicitly indicated in the figure (but implied), communication key-set ⁇ ck ⁇ i may also be stored in WORM memory 7 for convenience, and state values may be stored, at least temporally, in working memory of machine M i in operation.
- the refresh server RS i of each server system 2 comprises functionality for implementing the refresh operation to be described, and is adapted for secure communications with the machine management server MS i for this operation.
- the servers RS i and MS i can thus communicate via some secure channel 8 which is protected from the network 3 , which is generally considered insecure, via which machines M i communicate.
- Secure channel 8 can be protected by any convenient hardware and/or software mechanisms, and may be provided via a local or other network which is physically isolated or otherwise logically distinct from network 3 .
- Secure channel 8 may, for instance, be established via a standard security protocol such as TLS (Transport Security Layer) or SSL (Secure Sockets Layer).
- FIG. 2 is a block diagram of exemplary computing apparatus for implementing a computer of server system 2 .
- the computing apparatus is shown in the form of a general-purpose computer 10 .
- the components of computer 10 may include processing apparatus such as one or more processors represented by processing unit 11 , a system memory 12 , and a bus 13 that couples various system components including system memory 12 to processing unit 11 .
- Bus 13 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.
- bus architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
- Computer 10 typically includes a variety of computer readable media. Such media may be any available media that is accessible by computer 10 including volatile and non-volatile media, and removable and non-removable media.
- system memory 12 can include computer readable media in the form of volatile memory, such as random access memory (RAM) 14 and/or cache memory 15 .
- Computer 10 may further include other removable/non-removable, volatile/non-volatile computer system storage media.
- storage system 16 can be provided for reading from and writing to a non-removable, non-volatile magnetic medium (commonly called a “hard drive”).
- a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”)
- an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media
- each can be connected to bus 13 by one or more data media interfaces.
- Memory 12 may include at least one program product having one or more program modules that are configured to carry out functions of embodiments of the invention.
- program/utility 17 having a set (at least one) of program modules 18 , may be stored in memory 12 , as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment.
- Program modules 18 generally carry out the functions and/or methodologies of embodiments of the invention as described herein.
- Computer 10 may also communicate with: one or more external devices 19 such as a keyboard, a pointing device, a display 20 , etc.; one or more devices that enable a user to interact with computer 10 ; and/or any devices (e.g., network card, modem, etc.) that enable computer 10 to communicate with one or more other computing devices. Such communication can occur via input/output (I/O) interfaces 21 . Also, computer 10 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 22 . As depicted, network adapter 22 communicates with the other components of computer 10 via bus 13 .
- LAN local area network
- WAN wide area network
- public network e.g., the Internet
- each server system S i is adapted, for each of successive new time periods in operation of the protocol, to perform a refresh operation for that system.
- the time periods, or “epochs,” for which the refresh operation is performed may be defined in various ways in the system.
- the refresh operation may be performed automatically for epochs of a predetermined duration, and/or a new epoch may be initiated in response to detection of an attack on system 1 .
- FIG. 3 gives an overview of at least a portion of the main steps performed by a server system S i in the refresh operation for a new epoch.
- step 30 the refresh server RS i retrieves the state information st i stored in WORM memory 7 through communication with machine management server MS i via secure channel 8 .
- step 31 the refresh server RS i generates a new set of communication keys ⁇ ck ⁇ i for use in the new epoch.
- step 32 refresh server RS i sends the retrieved state information st i and the new set of keys ⁇ ck ⁇ i to the machine management server MS i via secure channel 8 .
- the machine management server MS i configures a new virtual machine M i ′ for implementing the protocol, whereby the new virtual machine receives the new set of keys ⁇ ck ⁇ i and state information st i sent by the refresh server.
- the new virtual machine M i ′ is thus set up with a fresh (clean) machine image img i , comprising the operating system and all applications running on it and including the functionality for implementing the cryptographic protocol.
- This machine image img i can be updated with all the latest security patches of the operating system and overlying applications.
- the fresh image img i may be constructed by refresh server RS i or machine management server MS i , or obtained from any convenient source.
- the new key-set ⁇ ck ⁇ i and state information st i may be embedded in the image img i by the refresh server RS i or machine management server MS i for booting the new machine M i ′, or this information may be supplied separately to the machine M i ′.
- the new virtual machine M i ′ assumes operation as the current virtual machine M i for the new epoch. This step can be implemented in a variety of ways, some of which are discussed below.
- the new virtual machine M i ′ stores state information sty for the new epoch in WORM memory 7 .
- the state information st i for the new epoch may include values inherited from the previous epoch (supplied by the refresh server in step 32 above) and/or new values generated for the new epoch based on the previous state.
- the new machine M i ′ may communicate with other server systems S j to update some state values as described further below.
- State information for the new epoch may therefore be stored in WORM memory 7 before and/or after the new machine M i ′ assumes operation as current machine M i for the epoch.
- new state values will be stored in WORM memory 7 immediately they are generated.
- server systems S i described above provides an efficient and elegantly simple mechanism for implementing proactive security.
- a fresh virtual machine M i is instantiated for each new epoch, avoiding inherited security issues due to machine compromise in prior epochs.
- the WORM memory prohibits over-writing of stored state information for an epoch, and the refresh server allows the necessary state information to be securely provided to the fresh machine together with fresh communication keys for each epoch. If a protocol machine M i is hacked, the adversary cannot change previously stored state information, and can only add additional values.
- Preferred embodiments described below additionally provide for authentication of stored state information.
- FIG. 4 A preferred implementation for server system S i is illustrated in FIG. 4 , according to an embodiment of the invention.
- a WORM object store 44 provided by cloud platform 42 stores the state information st i for the current virtual machine M i ( ⁇ ) as described above.
- a refresh server 45 communicates with cloud platform 42 via a secure network 46 in this embodiment.
- the key-set ⁇ ck ⁇ i used by current virtual machine M i ( ⁇ ) in this embodiment comprises a machine signing-key pair (pk i , sk i ), where pk i is a public machine key and sk i is a secret machine key.
- the machine M i ( ⁇ ) also stores a key-share k i of a cryptographic key K which is shared between the n server systems implementing the distributed protocol.
- This key-share k i forms at least a part of the state information st i stored in WORM memory 44 .
- the key-share is cryptographically signed by machine M i ( ⁇ ) when stored in WORM memory 44 as explained below.
- the refresh server 45 of this embodiment stores a server signing-key pair (Rpk i , Rsk i ), where Rpk i is a public server signing key and Rsk i is a secret server signing key.
- Refresh server 45 may also store a server encryption-key pair (Epk i , Esk i ), where Epk i is a public server encryption key and Esk i is a secret server encryption key. Public keys of the foregoing key-pairs are published in the distributed system as required.
- the cloud platform 42 may in general comprise one or more computers each supporting one or more virtual machines.
- cloud platform 42 can be realized by a single physical machine or a cluster of physical machines.
- the refresh server 45 may comprise a single physical machine in this embodiment. This machine is connected only to the cloud software platform, and such connections can be physically isolated from the network (in this example the Internet) via which the virtual machines 43 communicate.
- the virtual machines M i (0) , M i (1) , M i (2) , . . . are exposed to the Internet, while the cloud platform 42 and refresh server 45 are run in a protected environment (the “de-militarized zone”); i.e., behind one or more firewalls deployed in the cloud platform.
- the refresh server 45 is thus inaccessible from the Internet in normal operation of the cryptographic protocol, and is therefore protected from unauthorized Internet access. (Authorized access may of course be possible if required, e.g. for setup purposes prior to operation).
- server system 40 can exploit inherent features of modern cloud computing platforms such as, for instance, the OpenStack platform.
- cloud computing platforms such as, for instance, the OpenStack platform.
- Such platforms offer strong separation between the virtual machines which are exposed to the Internet, and are thus subject to attacks, and the cloud management interfaces that run in the demilitarized zone.
- New virtual machines can be created on the fly from images, machines can be shut down, and the routing of traffic to machines be dynamically configured.
- the platforms can also virtualize the storage for the virtual machines, offering different kinds of abstraction of hard-disks (such as file system, block store, object store, etc.).
- System setup can be managed as a manual process via a web interface in the de-militarized zone. However, system management operations can easily be automated with scripts to replace manual interaction with software-based control.
- the number of key-shares k i required here depends on the nature of the key-sharing scheme. Some schemes are so-called “n-out-of-n” schemes which require all key-shares k to reconstruct the shared key K. Other schemes are so-called threshold (or “t-out-of-n”) schemes in which only a threshold number t ⁇ n of the key-shares are required. Time is divided into epochs separated by refresh operations performed by the n server systems 40 . FIG. 5 indicates exemplary steps of this refresh operation, according to one or more embodiments of the invention.
- the refresh server RS i communicates with machine management server MS i via secure network 46 to retrieve the state information st i , comprising the signed key-share k i , stored in WORM memory 44 .
- the key-share k i generated by current machine M i ( ⁇ ) as described below, is signed by M i ( ⁇ ) using its secret machine key sk i , the resulting signed key-share being stored in WORM memory 44 .
- refresh server RS i authenticates the signed key-share k i by verifying the signature using the machine public key pk i . Any other state information retrieved in step 50 may be similarly signed by M i ( ⁇ ) and authenticated by RS i in this step.
- the refresh server RS i In step 52 , the refresh server RS i generates a new machine signing-key pair (pk i , sk i ) for the new epoch ( ⁇ +1). In step 53 of this embodiment, the refresh server signs the new public machine key pk i with the secret server signing key Rsk i to produce a server signature ⁇ R i . In this example, the refresh server RS i generates the clean image img i for the new virtual machine M i ( ⁇ +1) .
- RS i instructs machine management server MS i to start M i ( ⁇ +1) , sending MS i the clean image img i , the state information st i and the new machine signing-key pair (pk i , sk i ), with associated server signature ⁇ R i .
- the values st i , (pk i , sk i ), and ⁇ R i can be injected by RS i into the image img i supplied to MS i here.
- the machine management server then configures a new virtual machine M i ( ⁇ +1) with the image img i , and starts the new machine.
- the new machine M i ( ⁇ +1) sends its new public machine key pk i , and accompanying server signature ⁇ R i , via the Internet to each of the (n ⁇ 1) other server systems S j .
- the identities, i.e. IP addresses of all machines are assumed to be known to all other machines here. This can be achieved in various ways, e.g. by assigning addresses to machines in some pre-agreed fashion, as will be apparent to those skilled in the art).
- the new machine M i ( ⁇ +1) thus receives a corresponding new public machine key pk j , and corresponding server signature ⁇ R j , from each other server system S j as indicated at step 57 .
- step 58 the new machine M i ( ⁇ +1) authenticates each server signature ⁇ R j for pk j using the public server signing key Rpk j for that system. In this way, all public machine signing keys in the distributed system can be authenticated as genuine keys issued by the secure refresh servers of the system.
- step 59 the new virtual machine M i ( ⁇ +1) communicates with the new machines M j ( ⁇ +1) of other server systems S j to generate a new key-share k i for the new epoch.
- the precise steps performed here will depend upon specifics of the distributed protocol.
- refresh of the key-shares may be achieved as follows, according to one or more embodiments of the invention.
- each new machine M i ( ⁇ +1) computes random shares of the current key-share k i supplied by the refresh server.
- n and thus comprise one share k (i, j) for each of the n systems S j .
- the new machine M i ( ⁇ +1) then sends the other systems' shares ⁇ k (i,j) ⁇ j ⁇ i to respective systems S j , and deletes the old key-share k i .
- new machine M i ( ⁇ +1) will possess n shares k (1,i) , . . . , k (n,i) , and from these computes its new key-share k i .
- the computation here again depends on the particular secret sharing scheme. By way of example, however, for linear secret sharing schemes the computation may be:
- the new machine M i ( ⁇ +1) stores its newly-generated key-share k i in its WORM object store 44 in step 60 .
- M i ( ⁇ +1) signs the new key-share k i using its new secret key sk i , and stores the resulting signed key-share (comprising the new k i and a machine signature ⁇ M i thereon) in WORM memory 44 .
- other state information for the protocol may be generated by new machine M i ( ⁇ +1) in this preliminary phase, and such information can be similarly signed and stored in WORM memory 44 .
- Any other state information sent by the refresh server in step 54 and relevant to the new epoch, or state information received from other systems S j may be stored in the WORM memory in this or an earlier step, and may be signed by M i ( ⁇ +1) as appropriate.
- step 61 new machine M i ( ⁇ +1) notifies the refresh server RS i , via machine management server MS i , that the initialization operation is complete.
- the refresh servers RS i of systems S i may then synchronize (e.g. through Internet communications via MS i ) and agree on switching protocol operation to the new machines M i ( ⁇ +1) .
- switching times may be predetermined in the system, or controlled in other ways as discussed below.
- the refresh server RS i instructs machine management server MS i to activate the new machine M i ( ⁇ +1) for the protocol.
- This step may involve a command to MS i to switch the IP address of the current machine for the protocol, or to attach the new machine M i ( ⁇ +1) to a different network, etc.
- the machine management server MS i activates the new machine M i ( ⁇ +1) accordingly, and the new machine assumes operation as the current machine M i for the new epoch. All protocol communications can then be authenticated using the new machine signing-key pair (pk i , sk i ). Any additional state information generated by this machine in the new epoch will be stored in WORM memory 44 , preferably signed with sk i as described above.
- the machine management server MS i will switch off and delete the machine M i ( ⁇ ) for the previous epoch, e.g. on command from RS i .
- the above system allows secure refresh as before, and also permits authentication of state information by the refresh server RS i through verification of machine signatures on retrieval. All public machine signing keys can also be authenticated based on the refresh server signatures ⁇ R i .
- the server signing-key pair (Rpk i , Rsk i ) can be certified by a trusted Certification Authority, and the root signature for this certification can be embedded in all machine images img i . Whenever a signature is checked with respect to Rpk i , the certificate on Rpk i can be verified with respect to the root certificate in known manner.
- each new virtual machine M i ( ⁇ ) can be adapted to encrypt state information generated by that machine and stored in the WORM memory (plus state information received from other machines if desired), with the public server encryption key Epk i .
- the refresh server RS i uses its secret server encryption key Esk i to decrypt the encrypted state information retrieved from the WORM memory in the refresh operation.
- the set of communication keys ⁇ ck ⁇ i may include additional key-pairs, e.g. different key-pairs for communications with different systems S j , which can be treated in like manner to (pk i , sk i ) above.
- the key-set ⁇ ck ⁇ i may further include one or more machine encryption-key pairs (epk i , esk i ), epk i being a public machine encryption key and esk i a secret machine encryption key, to allow the current virtual machine to encrypt communications with other server systems S j using its secret machine encryption key sk i .
- the protocol key K shared between systems S i may be a secret (asymmetric) key or a symmetric key.
- the activation of new virtual machines may be managed in other ways to that described above.
- the new machine M i ( ⁇ +1) may notify a load balancer for the distributed system when it has completed its initialization procedure, and the load balancer may control activation for the new epoch if all, or sufficiently many, machines M i ( ⁇ +1) in the system have given notification.
- the threshold number t of machines it may be sufficient for the threshold number t of machines to be ready for activation.
- the refresh server RS i may similarly control machine activation based on readiness of a threshold number of machines.
- Embodiments may be envisaged wherein a refresh server is shared by more than one server system S i , and/or a given cloud platform implements more than one machine management server MS i .
- steps shown in flow diagrams may be performed in a different order to that indicated, and some steps may be performed concurrently, as appropriate, particularly in a distributed computing environment.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Storage Device Security (AREA)
Abstract
Description
- The present invention relates generally to server systems for implementing distributed cryptographic protocols, and more specifically to server systems providing proactive security in such protocols.
- Protecting information is essential in the digital economy. A common way to protect data is to use cryptographic protocols to process the data in some way, but it is then necessary to protect the state information for such protocols. This state information comprises the secret values, such as cryptographic keys, used by servers which implement the cryptographic algorithms. To reduce exposure to offline attack through server compromise, cryptographic protocols may be implemented in a distributed fashion. In distributed protocols, a plurality of servers communicate via a network to collectively implement the protocol. This enhances security because protocol operation requires cooperation of more than one server, so more than one server must be hacked for the protocol to be subverted. It is common practice, for example, to distribute (secret share) cryptographic keys between a plurality of servers which can perform operations with the shared key in a distributed fashion to collectively implement some protocol. Cryptography offers a rich body of distributed protocols including secret sharing schemes, signature schemes and encryption schemes, as well as more advanced protocols such as threshold password-authenticated secret sharing schemes.
- Resistance against server compromise is one thing, but knowing how to recover from such an event is another. In cryptographic literature, recovery from compromise is known as proactive security, or security against transient corruptions. Known schemes with proactive security allow a secret key to be refreshed by periodically re-sharing the key among the servers. The servers engage in an interactive refresh protocol to re-compute their key-shares for each new time period in operation of the distributed protocol.
- According to at least one embodiment of the present invention there is provided server system for operation as one of multiple such server systems, connectable via a network, to implement a distributed cryptographic protocol. The server system includes a machine management server which is operable to provide a plurality of virtual machines. The machine management server includes a current virtual machine which is adapted to implement the protocol using a set of communication keys, for communications with other said server systems via the network, and state information for the protocol. The server system further comprises a memory, operatively associated with the machine management server, for storing the state information, and a refresh server which is adapted for secure communications with the machine management server. The server system is configured, for each of successive new time periods in operation of the protocol, to perform a refresh operation in which: the refresh server retrieves the state information from the memory, generates a new set of communication keys, and sends the state information and new set of keys to the machine management server; the machine management server configures a new virtual machine for implementing the protocol, whereby the new virtual machine receives the new set of keys and state information sent by the refresh server; and the new virtual machine assumes operation as the current virtual machine for the new time period and stores state information for that time period in the memory.
- Embodiments of the invention will be described in more detail below, by way of illustrative and non-limiting example, with reference to the accompanying drawings.
- The following drawings are presented by way of example only and without limitation, wherein like reference numerals (when used) indicate corresponding elements throughout the several views, and wherein:
-
FIG. 1 is a schematic representation of a distributed system including server systems embodying the invention; -
FIG. 2 is a generalized schematic of a computer in a server system ofFIG. 1 ; -
FIG. 3 indicates steps performed in a refresh operation of a server system ofFIG. 1 ; -
FIG. 4 is a schematic representation of an embodiment of the server system; and -
FIG. 5 indicates steps performed in a refresh operation of theFIG. 4 system. - It is to be appreciated that elements in the figures are illustrated for simplicity and clarity. Common but well-understood elements that may be useful or necessary in a commercially feasible embodiment may not be shown in order to facilitate a less hindered view of the illustrated embodiments.
- Principles of the present invention will be described herein in the context of illustrative server apparatus and methods for implementing a distributed cryptographic protocol. It is to be appreciated, however, that the invention is not limited to the specific apparatus and/or methods illustratively shown and described herein. Rather, it will become apparent to those skilled in the art given the teachings herein that numerous modifications can be made to the embodiments shown that are within the scope of the claimed invention. That is, no limitations with respect to the embodiments shown and described herein are intended or should be inferred.
-
FIG. 1 is a schematic block diagram of adistributed processing system 1 comprising a plurality n ofservers systems 2 embodying the invention. The server systems are denoted by Si(1≦i≦n), where in general n≧2, and preferably n>2. In general, higher values of n offer greater security against offline attack through server compromise. The value of n can thus be selected according to security requirements for a given system. The server systems S1, . . . , Sn are connectable via a network 3 (which may in general comprise one or more component networks and/or internetworks, including the Internet) to implement a distributed cryptographic protocol. The cryptographic protocol may, for instance, comprise a secret sharing scheme, a signature scheme, an encryption scheme, or a password-authentication scheme. However, the particular functionality of the cryptographic protocol is orthogonal to the system operation to be described. - Each
server system 2 comprises arefresh server 4 and amachine management server 5 as illustrated for server system Si in the figure (the additional server systems Si, i>1, being shown in abstracted form for simplicity). Therefresh server 4 of system Si is denoted by RSi. MSi denotes themachine management server 5 of system Si. Each machine management server MSi is operable to provide a plurality of virtual machines, and includes a current virtual machine 6, denoted by Mi. The current virtual machine Mi is adapted to implement the cryptographic protocol in communication with the current virtual machines Mj, j≠i, ofother server systems 2 via network 3. To implement the protocol, each current machine Mi uses a set of cryptographic communication keys, denoted by {ck}i, for communications withother server systems 2, and state information sti for the protocol. The key-set {ck}i may in general comprise one or more communication keys which are used to process messages communicated between servers, e.g. for message encryption and/or authentication purposes, and typically comprises at least one public/private key pair in accordance with a PKI (Public Key Infrastructure) system. (PKI systems are well known in the art and the operational details are orthogonal to systems described herein). The state information sti generally comprises one or more values which are used by current machine Mi when running the protocol, and typically includes multiple values which may relate to the local machine state and/or the overall protocol state. Such values typically include at least one secret cryptographic key or key-share (secret to one or more machines Mi) which is required for correct operation of the protocol. This state information sti is stored, in one or more embodiments, in a WORM (write once read many) memory which is operatively associated with machine management server. State information sti can thus be written toWORM memory 7 by current machine Mi, and can be accessed as required via the MSi, but is protected against over-writing in the memory. While not explicitly indicated in the figure (but implied), communication key-set {ck}i may also be stored inWORM memory 7 for convenience, and state values may be stored, at least temporally, in working memory of machine Mi in operation. - The refresh server RSi of each
server system 2 comprises functionality for implementing the refresh operation to be described, and is adapted for secure communications with the machine management server MSi for this operation. The servers RSi and MSi can thus communicate via somesecure channel 8 which is protected from the network 3, which is generally considered insecure, via which machines Mi communicate.Secure channel 8 can be protected by any convenient hardware and/or software mechanisms, and may be provided via a local or other network which is physically isolated or otherwise logically distinct from network 3.Secure channel 8 may, for instance, be established via a standard security protocol such as TLS (Transport Security Layer) or SSL (Secure Sockets Layer). - Each of the refresh and
machine management servers server system 2 can be implemented by computing apparatus comprising one or more general- or special-purpose computers, each comprising one or more real or virtual machines, providing functionality for implementing the operations described herein.FIG. 2 is a block diagram of exemplary computing apparatus for implementing a computer ofserver system 2. The computing apparatus is shown in the form of a general-purpose computer 10. The components ofcomputer 10 may include processing apparatus such as one or more processors represented byprocessing unit 11, asystem memory 12, and abus 13 that couples various system components includingsystem memory 12 toprocessing unit 11. -
Bus 13 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. -
Computer 10 typically includes a variety of computer readable media. Such media may be any available media that is accessible bycomputer 10 including volatile and non-volatile media, and removable and non-removable media. For example,system memory 12 can include computer readable media in the form of volatile memory, such as random access memory (RAM) 14 and/orcache memory 15.Computer 10 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only,storage system 16 can be provided for reading from and writing to a non-removable, non-volatile magnetic medium (commonly called a “hard drive”). Although not explicitly shown (but implied), a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can also be provided. In such instances, each can be connected tobus 13 by one or more data media interfaces. -
Memory 12 may include at least one program product having one or more program modules that are configured to carry out functions of embodiments of the invention. By way of example, program/utility 17, having a set (at least one) ofprogram modules 18, may be stored inmemory 12, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment.Program modules 18 generally carry out the functions and/or methodologies of embodiments of the invention as described herein. -
Computer 10 may also communicate with: one or moreexternal devices 19 such as a keyboard, a pointing device, adisplay 20, etc.; one or more devices that enable a user to interact withcomputer 10; and/or any devices (e.g., network card, modem, etc.) that enablecomputer 10 to communicate with one or more other computing devices. Such communication can occur via input/output (I/O) interfaces 21. Also,computer 10 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) vianetwork adapter 22. As depicted,network adapter 22 communicates with the other components ofcomputer 10 viabus 13. It should be understood that although not explicitly shown (but implied), other hardware and/or software components could be used in conjunction withcomputer 10. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, redundant array of independent disks/drives (RAID) systems, tape drives, and data archival storage systems, etc. - In operation of
system 1, the current virtual machines Mi ofserver systems 2 communicate via network 3 to collectively implement the distributed protocol using their respective communication keys {ck}i and state information sti. Proactive security is provided in the system by periodic performance of a refresh operation. In particular, each server system Si is adapted, for each of successive new time periods in operation of the protocol, to perform a refresh operation for that system. The time periods, or “epochs,” for which the refresh operation is performed may be defined in various ways in the system. For example, the refresh operation may be performed automatically for epochs of a predetermined duration, and/or a new epoch may be initiated in response to detection of an attack onsystem 1.FIG. 3 gives an overview of at least a portion of the main steps performed by a server system Si in the refresh operation for a new epoch. - With reference to
FIG. 3 , in a first step,step 30, of the refresh operation, the refresh server RSi retrieves the state information sti stored inWORM memory 7 through communication with machine management server MSi viasecure channel 8. Instep 31, the refresh server RSi generates a new set of communication keys {ck}i for use in the new epoch. Instep 32, refresh server RSi sends the retrieved state information sti and the new set of keys {ck}i to the machine management server MSi viasecure channel 8. Instep 33, the machine management server MSi configures a new virtual machine Mi′ for implementing the protocol, whereby the new virtual machine receives the new set of keys {ck}i and state information sti sent by the refresh server. The new virtual machine Mi′ is thus set up with a fresh (clean) machine image imgi, comprising the operating system and all applications running on it and including the functionality for implementing the cryptographic protocol. This machine image imgi can be updated with all the latest security patches of the operating system and overlying applications. In general, the fresh image imgi may be constructed by refresh server RSi or machine management server MSi, or obtained from any convenient source. The new key-set {ck}i and state information sti may be embedded in the image imgi by the refresh server RSi or machine management server MSi for booting the new machine Mi′, or this information may be supplied separately to the machine Mi′. Instep 34, the new virtual machine Mi′ assumes operation as the current virtual machine Mi for the new epoch. This step can be implemented in a variety of ways, some of which are discussed below. As indicated atstep 35, the new virtual machine Mi′ stores state information sty for the new epoch inWORM memory 7. The state information sti for the new epoch may include values inherited from the previous epoch (supplied by the refresh server instep 32 above) and/or new values generated for the new epoch based on the previous state. For example, the new machine Mi′ may communicate with other server systems Sj to update some state values as described further below. State information for the new epoch may therefore be stored inWORM memory 7 before and/or after the new machine Mi′ assumes operation as current machine Mi for the epoch. In preferred embodiments, new state values will be stored inWORM memory 7 immediately they are generated. - The arrangement and operation of server systems Si described above provides an efficient and elegantly simple mechanism for implementing proactive security. A fresh virtual machine Mi is instantiated for each new epoch, avoiding inherited security issues due to machine compromise in prior epochs. The WORM memory prohibits over-writing of stored state information for an epoch, and the refresh server allows the necessary state information to be securely provided to the fresh machine together with fresh communication keys for each epoch. If a protocol machine Mi is hacked, the adversary cannot change previously stored state information, and can only add additional values. Preferred embodiments described below additionally provide for authentication of stored state information.
- A preferred implementation for server system Si is illustrated in
FIG. 4 , according to an embodiment of the invention. In thesystem 40 of this example, themachine management server 41 is implemented by acloud computing platform 42 which runs a currentvirtual machine 43, denoted by Mi (ε) (where ε=0, 1, 2, etc., indicates epoch number). A fresh virtual machine Mi (0), Mi (1), Mi (2), etc., is initiated onplatform 42 for each of successive epochs ε=0, 1, 2, . . . , . AWORM object store 44 provided bycloud platform 42 stores the state information sti for the current virtual machine Mi (ε) as described above. Arefresh server 45 communicates withcloud platform 42 via asecure network 46 in this embodiment. - The key-set {ck}i used by current virtual machine Mi (ε) in this embodiment comprises a machine signing-key pair (pki, ski), where pki is a public machine key and ski is a secret machine key. The machine Mi (ε) also stores a key-share ki of a cryptographic key K which is shared between the n server systems implementing the distributed protocol. This key-share ki forms at least a part of the state information sti stored in
WORM memory 44. In this illustrative embodiment, the key-share is cryptographically signed by machine Mi (ε) when stored inWORM memory 44 as explained below. Therefresh server 45 of this embodiment stores a server signing-key pair (Rpki, Rski), where Rpki is a public server signing key and Rski is a secret server signing key.Refresh server 45 may also store a server encryption-key pair (Epki, Eski), where Epki is a public server encryption key and Eski is a secret server encryption key. Public keys of the foregoing key-pairs are published in the distributed system as required. - The
cloud platform 42 may in general comprise one or more computers each supporting one or more virtual machines. In a typical implementation,cloud platform 42 can be realized by a single physical machine or a cluster of physical machines. Therefresh server 45 may comprise a single physical machine in this embodiment. This machine is connected only to the cloud software platform, and such connections can be physically isolated from the network (in this example the Internet) via which thevirtual machines 43 communicate. In particular, the virtual machines Mi (0), Mi (1), Mi (2), . . . , are exposed to the Internet, while thecloud platform 42 and refreshserver 45 are run in a protected environment (the “de-militarized zone”); i.e., behind one or more firewalls deployed in the cloud platform. Therefresh server 45 is thus inaccessible from the Internet in normal operation of the cryptographic protocol, and is therefore protected from unauthorized Internet access. (Authorized access may of course be possible if required, e.g. for setup purposes prior to operation). - With the implementation of
FIG. 4 ,server system 40 can exploit inherent features of modern cloud computing platforms such as, for instance, the OpenStack platform. Such platforms offer strong separation between the virtual machines which are exposed to the Internet, and are thus subject to attacks, and the cloud management interfaces that run in the demilitarized zone. New virtual machines can be created on the fly from images, machines can be shut down, and the routing of traffic to machines be dynamically configured. The platforms can also virtualize the storage for the virtual machines, offering different kinds of abstraction of hard-disks (such as file system, block store, object store, etc.). System setup can be managed as a manual process via a web interface in the de-militarized zone. However, system management operations can easily be automated with scripts to replace manual interaction with software-based control. - In operation of the distributed protocol, according to one or more embodiments, the n virtual machines Mi (ε), i=1 to n, communicate to implement a cryptographic protocol in which the key shares ki of a plurality of the machines Mi (ε) can be combined to reconstruct the cryptographic key K for the protocol. The number of key-shares ki required here depends on the nature of the key-sharing scheme. Some schemes are so-called “n-out-of-n” schemes which require all key-shares k to reconstruct the shared key K. Other schemes are so-called threshold (or “t-out-of-n”) schemes in which only a threshold number t≦n of the key-shares are required. Time is divided into epochs separated by refresh operations performed by the
n server systems 40.FIG. 5 indicates exemplary steps of this refresh operation, according to one or more embodiments of the invention. - In
step 50 ofFIG. 5 , the refresh server RSi communicates with machine management server MSi viasecure network 46 to retrieve the state information sti, comprising the signed key-share ki, stored inWORM memory 44. In particular, the key-share ki, generated by current machine Mi (ε) as described below, is signed by Mi (ε) using its secret machine key ski, the resulting signed key-share being stored inWORM memory 44. Instep 51, refresh server RSi authenticates the signed key-share ki by verifying the signature using the machine public key pki. Any other state information retrieved instep 50 may be similarly signed by Mi (ε) and authenticated by RSi in this step. - In
step 52, the refresh server RSi generates a new machine signing-key pair (pki, ski) for the new epoch (ε+1). Instep 53 of this embodiment, the refresh server signs the new public machine key pki with the secret server signing key Rski to produce a server signature σRi. In this example, the refresh server RSi generates the clean image imgi for the new virtual machine Mi (ε+1). Instep 54, RSi instructs machine management server MSi to start Mi (ε+1), sending MSi the clean image imgi, the state information sti and the new machine signing-key pair (pki, ski), with associated server signature σRi. The values sti, (pki, ski), and σRi can be injected by RSi into the image imgi supplied to MSi here. Instep 55, the machine management server then configures a new virtual machine Mi (ε+1) with the image imgi, and starts the new machine. - In
step 56, the new machine Mi (ε+1) sends its new public machine key pki, and accompanying server signature σRi, via the Internet to each of the (n−1) other server systems Sj. (The identities, i.e. IP addresses of all machines are assumed to be known to all other machines here. This can be achieved in various ways, e.g. by assigning addresses to machines in some pre-agreed fashion, as will be apparent to those skilled in the art). The new machine Mi (ε+1) thus receives a corresponding new public machine key pkj, and corresponding server signature σRj, from each other server system Sj as indicated at step 57. Instep 58, the new machine Mi (ε+1) authenticates each server signature σRj for pkj using the public server signing key Rpkj for that system. In this way, all public machine signing keys in the distributed system can be authenticated as genuine keys issued by the secure refresh servers of the system. - In
step 59, the new virtual machine Mi (ε+1) communicates with the new machines Mj (ε+1) of other server systems Sj to generate a new key-share ki for the new epoch. The precise steps performed here will depend upon specifics of the distributed protocol. By way of example, however, refresh of the key-shares may be achieved as follows, according to one or more embodiments of the invention. First, each new machine Mi (ε+1) computes random shares of the current key-share ki supplied by the refresh server. The resulting random shares are denoted by {k(i,j)}j=1, . . . , n, and thus comprise one share k(i, j) for each of the n systems Sj. The new machine Mi (ε+1) then sends the other systems' shares {k(i,j)}j≠i to respective systems Sj, and deletes the old key-share ki. Following this process, new machine Mi (ε+1) will possess n shares k(1,i), . . . , k(n,i), and from these computes its new key-share ki. The computation here again depends on the particular secret sharing scheme. By way of example, however, for linear secret sharing schemes the computation may be: -
new kiΘj=1 nk(j,i). - Note that these and all further communications between the new virtual machines can be authenticated using the new machine signing-key pairs (pki, ski). That is, messages signed by a machine with its secret signing-key ski can be verified by a receiver using the corresponding public key pki.
- The new machine Mi (ε+1) stores its newly-generated key-share ki in its
WORM object store 44 instep 60. In this embodiment, Mi (ε+1) signs the new key-share ki using its new secret key ski, and stores the resulting signed key-share (comprising the new ki and a machine signature σMi thereon) inWORM memory 44. In some embodiments, other state information for the protocol may be generated by new machine Mi (ε+1) in this preliminary phase, and such information can be similarly signed and stored inWORM memory 44. Any other state information sent by the refresh server instep 54 and relevant to the new epoch, or state information received from other systems Sj, may be stored in the WORM memory in this or an earlier step, and may be signed by Mi (ε+1) as appropriate. - In
step 61, new machine Mi (ε+1) notifies the refresh server RSi, via machine management server MSi, that the initialization operation is complete. The refresh servers RSi of systems Si may then synchronize (e.g. through Internet communications via MSi) and agree on switching protocol operation to the new machines Mi (ε+1). Alternatively, for example, switching times may be predetermined in the system, or controlled in other ways as discussed below. To start the new epoch here, instep 62 the refresh server RSi instructs machine management server MSi to activate the new machine Mi (ε+1) for the protocol. This step may involve a command to MSi to switch the IP address of the current machine for the protocol, or to attach the new machine Mi (ε+1) to a different network, etc. Instep 63, the machine management server MSi activates the new machine Mi (ε+1) accordingly, and the new machine assumes operation as the current machine Mi for the new epoch. All protocol communications can then be authenticated using the new machine signing-key pair (pki, ski). Any additional state information generated by this machine in the new epoch will be stored inWORM memory 44, preferably signed with ski as described above. After switching protocol operation to the new machine, instep 64 the machine management server MSi will switch off and delete the machine Mi (ε) for the previous epoch, e.g. on command from RSi. - The above system allows secure refresh as before, and also permits authentication of state information by the refresh server RSi through verification of machine signatures on retrieval. All public machine signing keys can also be authenticated based on the refresh server signatures σRi. The server signing-key pair (Rpki, Rski) can be certified by a trusted Certification Authority, and the root signature for this certification can be embedded in all machine images imgi. Whenever a signature is checked with respect to Rpki, the certificate on Rpki can be verified with respect to the root certificate in known manner.
- In a modification to the above embodiment where the refresh server RSi has an encryption-key pair (Epki, Eski), each new virtual machine Mi (ε) can be adapted to encrypt state information generated by that machine and stored in the WORM memory (plus state information received from other machines if desired), with the public server encryption key Epki. The refresh server RSi then uses its secret server encryption key Eski to decrypt the encrypted state information retrieved from the WORM memory in the refresh operation.
- Many other changes and modifications can, of course, be made to the exemplary embodiments described above that are within the scope of embodiments of the present invention. For example, the set of communication keys {ck}i may include additional key-pairs, e.g. different key-pairs for communications with different systems Sj, which can be treated in like manner to (pki, ski) above. The key-set {ck}i may further include one or more machine encryption-key pairs (epki, eski), epki being a public machine encryption key and eski a secret machine encryption key, to allow the current virtual machine to encrypt communications with other server systems Sj using its secret machine encryption key ski. The protocol key K shared between systems Si may be a secret (asymmetric) key or a symmetric key.
- The activation of new virtual machines may be managed in other ways to that described above. For example, the new machine Mi (ε+1) may notify a load balancer for the distributed system when it has completed its initialization procedure, and the load balancer may control activation for the new epoch if all, or sufficiently many, machines Mi (ε+1) in the system have given notification. For t-out-of-n threshold protocols in particular, it may be sufficient for the threshold number t of machines to be ready for activation. The refresh server RSi may similarly control machine activation based on readiness of a threshold number of machines.
- Embodiments may be envisaged wherein a refresh server is shared by more than one server system Si, and/or a given cloud platform implements more than one machine management server MSi. In general, steps shown in flow diagrams may be performed in a different order to that indicated, and some steps may be performed concurrently, as appropriate, particularly in a distributed computing environment.
- The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (11)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/928,813 US9641325B1 (en) | 2015-10-30 | 2015-10-30 | Server systems for distributed cryptographic protocols |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/928,813 US9641325B1 (en) | 2015-10-30 | 2015-10-30 | Server systems for distributed cryptographic protocols |
Publications (2)
Publication Number | Publication Date |
---|---|
US9641325B1 US9641325B1 (en) | 2017-05-02 |
US20170126412A1 true US20170126412A1 (en) | 2017-05-04 |
Family
ID=58629246
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/928,813 Expired - Fee Related US9641325B1 (en) | 2015-10-30 | 2015-10-30 | Server systems for distributed cryptographic protocols |
Country Status (1)
Country | Link |
---|---|
US (1) | US9641325B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109521702A (en) * | 2017-09-19 | 2019-03-26 | 蓝星(北京)技术中心有限公司 | A kind of method and server monitoring dcs operating status |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10979218B2 (en) | 2019-03-13 | 2021-04-13 | International Business Machines Corporation | Secret generation and share distribution |
US11641272B2 (en) * | 2020-09-18 | 2023-05-02 | Intel Corporation | Seamless one-way access to protected memory using accessor key identifier |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5625692A (en) * | 1995-01-23 | 1997-04-29 | International Business Machines Corporation | Method and system for a public key cryptosystem having proactive, robust, and recoverable distributed threshold secret sharing |
JP4071870B2 (en) * | 1998-08-20 | 2008-04-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Secret key generation method |
US8699715B1 (en) * | 2012-03-27 | 2014-04-15 | Emc Corporation | On-demand proactive epoch control for cryptographic devices |
US8909939B1 (en) * | 2012-04-04 | 2014-12-09 | Google Inc. | Distribution of cryptographic host keys in a cloud computing environment |
US8874904B1 (en) * | 2012-12-13 | 2014-10-28 | Emc Corporation | View computation and transmission for a set of keys refreshed over multiple epochs in a cryptographic device |
US8977847B1 (en) * | 2013-03-13 | 2015-03-10 | Emc Corporation | Distributed challenge-response authentication |
US9032212B1 (en) * | 2013-03-15 | 2015-05-12 | Emc Corporation | Self-refreshing distributed cryptography |
-
2015
- 2015-10-30 US US14/928,813 patent/US9641325B1/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109521702A (en) * | 2017-09-19 | 2019-03-26 | 蓝星(北京)技术中心有限公司 | A kind of method and server monitoring dcs operating status |
Also Published As
Publication number | Publication date |
---|---|
US9641325B1 (en) | 2017-05-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10454916B2 (en) | Systems and methods for implementing security | |
US11604901B2 (en) | Systems and methods for using extended hardware security modules | |
US8997198B1 (en) | Techniques for securing a centralized metadata distributed filesystem | |
US9098318B2 (en) | Computational asset identification without predetermined identifiers | |
US9143491B2 (en) | Quorum-based virtual machine security | |
CA2864347C (en) | Cloud-based key management | |
US9124640B2 (en) | Systems and methods for implementing computer security | |
US11469903B2 (en) | Autonomous signing management operations for a key distribution service | |
TW202015378A (en) | Cryptographic operation method, method for creating work key, and cryptographic service platform and device | |
WO2016128856A1 (en) | Automatic key management using enterprise user identity management | |
US20160241558A1 (en) | Automatic Key Management Using Enterprise User Identity Management | |
US9641325B1 (en) | Server systems for distributed cryptographic protocols | |
KR102017101B1 (en) | Internet of Things Security Module | |
US20160142205A1 (en) | Symmetric secret key protection | |
US11818264B2 (en) | Zero-knowledge key escrow | |
WO2022252356A1 (en) | Data processing method and apparatus, electronic device, and medium | |
Xiong et al. | Cloudsafe: Securing data processing within vulnerable virtualization environments in the cloud | |
AU2021235526B2 (en) | Secure private key distribution between endpoint instances | |
WO2012093924A1 (en) | System and method to provide trusted platform module (tpm) functionalities on a remote server for multiple users | |
Vatchala et al. | Auto Sec SDN-XTR: A Hybrid End to End Security Mechanism with Efficient Trace Representation on Open Stack Cloud. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CAMENISCH, JAN L.;KORONDI, MARK;KOVACS, DANIEL;AND OTHERS;SIGNING DATES FROM 20151020 TO 20151026;REEL/FRAME:036928/0443 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: AIRBNB, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:056427/0193 Effective date: 20210106 |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20210502 |