# Patent

## Title
Server systems for distributed cryptographic protocols

## Abstract

A server system for implementing a distributed cryptographic protocol includes a machine management server which comprises a current virtual machine configured to implement the protocol using a set of communication keys and state information for the protocol. The system further includes a memory and a refresh server. The system is configured, for each of successive new time periods in operation of the protocol, to perform a refresh operation wherein: 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.

## Background
BACKGROUND
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.
SUMMARY
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.



BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE 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 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; and
FIG. 5 indicates steps performed in a refresh operation of the FIG. 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.
DETAILED DESCRIPTION
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 a distributed processing system 1 comprising a plurality n of servers 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 a refresh server 4 and a machine management server 5 as illustrated for server system S1 in the figure (the additional server systems Si, i>1, being shown in abstracted form for simplicity). The refresh server 4 of system Si is denoted by RSi. MSi denotes the machine 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, of other 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 with other 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 to WORM 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 in WORM 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 some secure 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 4, 5 in a 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 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. 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 by computer 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/or cache 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 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. By way of example, 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. It should be understood that although not explicitly shown (but implied), other hardware and/or software components could be used in conjunction with computer 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 of server 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 on system 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 in WORM memory 7 through communication with machine management server MSi via secure channel 8. In step 31, the refresh server RSi generates a new set of communication keys {ck}i for use in the new epoch. In step 32, refresh server RSi sends the retrieved state information sti and the new set of keys {ck}i to the machine management server MSi via secure channel 8. In step 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′. In step 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 at step 35, the new virtual machine Mi′ stores state information sti for the new epoch in WORM memory 7. The state information sti 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. 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 in WORM 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 in WORM 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 the system 40 of this example, the machine management server 41 is implemented by a cloud computing platform 42 which runs a current virtual 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 on platform 42 for each of successive epochs ε=0, 1, 2, . . . , . A WORM object store 44 provided by cloud platform 42 stores the state information sti for the current virtual machine Mi(ε) 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 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 in WORM memory 44 as explained below. The refresh 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. 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. In particular, the virtual machines Mi(0), Mi(1), Mi(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).
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 ki 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 of FIG. 5, the refresh server RSi communicates with machine management server MSi via secure network 46 to retrieve the state information sti, comprising the signed key-share ki, stored in WORM 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 in WORM memory 44. In step 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 in step 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). In step 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). In step 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. In step 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. In step 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−1nk(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 in step 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) in WORM 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 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 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, in step 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. In step 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 in WORM memory 44, preferably signed with ski as described above. After switching protocol operation to the new machine, in step 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

1. A server system for operation as one of multiple such server systems connectable via a network to implement a distributed cryptographic protocol, the server system comprising:
a machine management server, configured to provide a plurality of virtual machines, including a current virtual machine which is adapted to implement said protocol using a set of communication keys, for communications with other said server systems via the network, and state information for the protocol;
a memory, operatively associated with the machine management server, for storing said state information; and
a refresh server configured for secure communications with the machine management server;
wherein 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 said 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 said current virtual machine for the new time period and stores state information for that time period in the memory.

2. The server system as recited in claim 1, wherein said set of communication keys comprises a machine signing-key pair (pki, ski), where pki is a public machine key and ski is a secret machine key, and wherein:
the new virtual machine is configured to sign state information generated by that machine with the secret machine key ski and to store the signed state information in the memory; and
the refresh server is configured to authenticate the signed state information, retrieved from the memory in the next refresh operation, using the public machine key pki.

3. The server system as recited in claim 2, wherein the refresh server stores a server signing-key pair (Rpki, Rski), where Rpki is a public server signing key and Rski is a secret server signing key, and wherein:
the refresh server is adapted to sign a new public machine key pki, of a new machine signing-key pair (pki, ski) generated in said refresh operation, with the secret server signing key Rski to produce a server signature σRi, and to send the server signature σRi to the machine management server with the new machine signing-key pair; and
the new virtual machine is adapted to send the server signature σRi and new public machine key pki via the network to the other said server systems.

4. The server system as recited in claim 3, wherein the new virtual machine is configured to authenticate a corresponding server signature σRj for a corresponding public machine key pkj received from another of said server systems using a public server signing key Rpkj for that system.

5. The server system as recited in claim 1, wherein said state information comprises a key-share ki of a cryptographic key K which is shared between the multiple server systems, and wherein the new virtual machine is configured to communicate with the other said server systems to generate a new key-share ki for the new time period, and to store the new key-share ki in the memory.

6. The server system as recited in claim 2, wherein said state information comprises a key-share ki of a cryptographic key K which is shared between the multiple server systems, and wherein the new virtual machine is configured to communicate with the other said server systems to generate a new key-share ki for the new time period, to sign the new key-share ki with said secret machine key ski, and to store the signed key-share in the memory.

7. The server system as recited in claim 1, wherein the refresh server stores a server encryption-key pair (Epki, Eski), where Epki is a public server encryption key and Eski is a secret server encryption key, and wherein:
the new virtual machine is adapted to encrypt state information generated by that machine, and stored in the memory, with the public server encryption key Epki; and
the refresh server is adapted to decrypt state information encrypted with the public server encryption key, and retrieved from the memory in said refresh operation, using the secret server encryption key Eski.

8. The server system as recited in claim 1, wherein the refresh server is further configured, in said refresh operation, to send the machine management server a machine image for configuring the new virtual machine.

9. The server system as recited in claim 1, wherein the machine management server comprises a cloud computing platform.

10. The server system as recited in claim 1, wherein the memory comprises write once read many (WORM) memory.

11. A distributed system comprising a plurality of server systems connected together via a network to implement a distributed cryptographic protocol, each of at least a subset of the plurality of server systems comprising:
a machine management server, configured to provide a plurality of virtual machines, including a current virtual machine which is adapted to implement said protocol using a set of communication keys, for communications with other said plurality of server systems via the network, and state information for the protocol;
a memory, operatively associated with the machine management server, for storing said state information; and
a refresh server configured for secure communications with the machine management server;
wherein 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 said 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 said current virtual machine for the new time period and stores state information for that time period in the memory.