The present invention relates to methods and devices for securing keys when key-management processes are subverted by an adversary, with applications to distributed environments.
A trend in modern computer networking, web-, and cloud-computing, is to rely on public, group, shared, or virtualized resources. The IT (information technology) marketplace offers public, private, and hybrid solutions for “virtualization” and “cloud computing.” Such a growing trend is occurring at many levels: infrastructure, platform, and software.
A recurring problem hampering such solutions is the fact that “networked,” “virtualized,” and/or “cloud” solutions are by their very nature non-secured and distributed. The resources may be physically owned by different entities other than the users, or may be shared among multiple users (having existing security, privacy, and trust concerns). This may occur within one legal entity or among different entities.
For example, a file may be saved in a network “storage cloud.” Since the storage cloud is a shared resource, a user is entrusting his/her data to a resource that is routinely accessed by many other users, over which the user has no control at all.
All modem computing systems share a concern that malicious attackers may breach the security of an environment and obtain some of its secrets. This general concern is even greater in public, group, virtualized or network-accessible environments—since the scope for an attacker to enter the system is commensurately greater.
Of course, one solution for the security-conscious consumer is to avoid shared resources altogether. However, such an option is an unpleasant choice for the user, since modern shared resources provide many economic, operational, and technical benefits.
It would be desirable to have methods and devices for securing keys when key-management processes are subverted by an adversary. Such methods and devices would, inter alia, overcome the limitations mentioned above.
It is the purpose of the present invention to provide methods and devices for securing keys when key-management processes are subverted by an adversary, with applications to distributed environments.
It is noted that the term “exemplary” is used herein to refer to examples of embodiments and/or implementations, and is not meant to necessarily convey a more-desirable use-case.
Therefore, it is understood from the above that “exemplary” may be applied herein to multiple embodiments and/or implementations.
Embodiments of the present invention enable the security-conscious customer to use available shared or distributed resources, and yet enjoy full security and control—with emphasis placed on key management.
“Keys” in this context may be any secret that can be called a key, as the term is used in the art, or indeed any secret phrase. The term “protected item” is also used to denote such secrets. Common examples would be the encryption key that is used to encrypt a large amount of data, or the access key that is used to gain access to a computing subsystem.
Assume that a key may be legitimately used by several entities in an environment (each is called an “appliance”); some of the appliances may create the key, while other appliances may use the key. Each such creation operation or usage operation may in principal be performed by the same or a different entity.
Also, the appliances are in communication with a Protected Virtual Key Manager (PVKM) which may provide services to the abovementioned appliances and to the users of the system. Such services are related to managing the keys of the system, and also related to enhancing the security of the system.
It is desirable that:
One way to protect keys is by encrypting the keys with a “key-encryption key,” also called a “master key.” But then the above requirements translate to requirements about the security of the master key. If data, the runtime state, or code is compromised, the master key must not be leaked.
In the interest of clarity, the terms “compromise” and “subversion” are specifically defined for use herein. One possible definition, which is used herein, is that the adversarial model is “semi honest.” In the semi-honest model as used herein, it is assumed that the computing entities (i.e., appliances and PVKM) have been implemented as specified, and the computing platform, on which such entities are implemented, actually runs the entities as implemented. In such a semi-honest model, an attacker may eavesdrop, but, by assumption, does not change such implementations.
A more stringent definition is that the security of the system, and in particular the security of a master key, is not compromised even if an attacker is able to arbitrarily deviate from the prescribed implementation (e.g., for an appliance or the PVKM). Such an adversarial model is referred to herein as the “malicious” model.
In such a malicious model, it is assumed that attackers may have taken over an appliance, or the PVKM, and changed its implementation arbitrarily, so that one or more entities (i.e., appliances or the PVKM) are now “malicious.” Security of the master key in such a malicious model means that the attackers will still never discover the master key, even when the attackers control malicious entities.
Embodiments of the present invention are resilient to subversion, even if an adversary has arbitrarily modified the implementation of an appliance or the implementation of the PVKM. Such embodiments are well-adapted to modern public, group, virtualized, or network-accessible environments.
Such distributed environments may involve situations were legitimate computing entities are joining and leaving a system all the time. Embodiments of the present invention are resilient to the compromise of key-management processes without depending on specific pieces of hardware but rather depending on algorithms or software that can be easily deployed to members of such a dynamic environment.
Therefore, according to the present invention, there is provided for the first time a method for securing keys when key-management processes are subverted by an adversary, the method including the steps of: (a) upon receiving a creation request in the computing-environment, creating a secure key in at least one location in a computing environment by repetitively computing respective secure-key contributions: (i) in at least one location; and (ii) in a set of N computing resources in the computing environment, wherein N is a non-negative integer; and (b) applying the respective secure-key contributions to change a secure-key value, wherein: (i) the respective secure-key contributions cannot be omitted or modified by at least one location; and (ii) the secure key is never revealed to the computing resources; thereby enabling the computing resources in the computing environment to ensure that the secure key is truly random; wherein at least one location is a region of memory located in a computing resource operationally connected to the computing-environment.
Alternatively, the respective secure-key contributions are random.
Alternatively, the respective secure-key contributions of the set of N computing resources are never revealed to at least one location.
Alternatively, a given, respective secure-key contribution of a given computing resource is never revealed to any other computing resource of the set of N computing resources, and wherein the secure-key in at least one location is never revealed to any other computing resource of the set of N computing resources.
Alternatively, the step of creating and the step of applying the respective secure-key contributions can be performed on any element of a collection of computing resources operationally connected to the computing-environment, and wherein the step of applying is performed differently on each element, thereby preventing subversion of one element from compromising any other element.
According to the present invention, there is provided for the first time a device for securing keys when key-management processes are subverted by an adversary, the device including: (a) a server including: (i) a CPU for performing computational operations; (ii) a memory module for storing data; and (iii) a network connection for communicating across a network; and (b) a protection module, residing on the server, configured for: (i) upon receiving a creation request in the computing-environment, creating a secure key in at least one location in a computing environment by repetitively computing respective secure-key contributions: (A) in at least one location; and (B) in a set of N computing resources in the computing environment, wherein N is a non-negative integer; and (ii) applying the respective secure-key contributions to change a secure-key value, wherein: (A) the respective secure-key contributions cannot be omitted or modified by at least one location; and (B) the secure key is never revealed to the computing resources; thereby enabling the computing resources in the computing environment to ensure that the secure key is truly random; wherein at least one location is a region of memory located in a computing resource operationally connected to the computing-environment.
Alternatively, the respective secure-key contributions are random.
Alternatively, the respective secure-key contributions of the set of N computing resources are never revealed to at least one location.
Alternatively, a given, respective secure-key contribution of a given computing resource is never revealed to any other computing resource of the set of N computing resources, and wherein the secure-key in at least one location is never revealed to any other computing resource of the set of N computing resources.
Alternatively, the creating and the applying the respective secure-key contributions can be performed on any element of a collection of computing resources operationally connected to the computing-environment, and wherein the applying is performed differently on each element, thereby preventing subversion of one element from compromising any other element.
According to the present invention, there is provided for the first time a non-transitory computer-readable medium, having computer-readable code embodied on the non-transitory computer-readable medium for securing keys when key-management processes are subverted by an adversary, the computer-readable code including: (a) program code for, upon receiving a creation request in the computing-environment, creating a secure key in at least one location in a computing environment by repetitively computing respective secure-key contributions: (i) in at least one location; and (ii) in a set of N computing resources in the computing environment, wherein N is a non-negative integer; and (b) program code for, applying the respective secure-key contributions to change a secure-key value, wherein: (i) the respective secure-key contributions cannot be omitted or modified by at least one location; and (ii) the secure key is never revealed to the computing resources; thereby enabling the computing resources in the computing environment to ensure that the secure key is truly random; wherein at least one location is a region of memory located in a computing resource operationally connected to the computing-environment.
Alternatively, the respective secure-key contributions are random.
Alternatively, the respective secure-key contributions of the set of N computing resources are never revealed to at least one location.
Alternatively, a given, respective secure-key contribution of a given computing resource is never revealed to any other computing resource of the set of N computing resources, and wherein the secure-key in at least one location is never revealed to any other computing resource of the set of N computing resources.
Alternatively, the creating and the applying the respective secure-key contributions can be performed on any element of a collection of computing resources operationally connected to the computing-environment, and wherein the applying is performed differently on each element, thereby preventing subversion of one said element from compromising any other element.
These and further embodiments will be apparent from the detailed description that follows.
The present invention is herein described, by way of example only, with reference to the accompanying drawings, wherein:
The present invention relates to methods and devices for securing keys when key-management processes are subverted by an adversary, with applications to distributed environments. The principles and operation for providing such methods and devices, according to the present invention, may be better understood with reference to the accompanying description and the drawings.
Consider a computing system (e.g., a software application) that includes multiple computing resources. Such resources may be defined broadly (e.g., data, secret phrases, keys, memory segments, storage areas, storage segments, networks, network segments, and computing resources. Some or all of such resources are protected by keys. It is required to use a master key (a “key-encryption key”) to secure some of the keys in the system. Since the master key is required to secure other keys in the system, it must be secured itself.
Since the security of the computing system is a concern, ideally the master key would be secured by keeping the key in a safe place, outside the computing system (or indeed, outside any computing system). At the same time, since the master key is needed to secure resources in the computing system, the master key must be inside the computing system.
Ideally, the master key could be used inside the computing system without ever having the key inside the computing system (or inside any computing system). Such a statement is not paradoxical, since such an objective may be achieved by employing methods that encrypt the key before the key enters any computing system, while performing the encryption in ways that still allow the key to be used.
Assume some key Km is used to protect another key, Ks, in the system. Km is the “master” key and Ks a “specific” key. The encryption of Ks by Km is denoted as:
K
m
⊖K
s Equation 1,
which is referred to as the “blinding” of Ks with Km, and in which ⊖ is a suitable operator. The inverse of ⊖ is “/” (sometimes represented by the symbol “÷”), so the decryption operation is (Km⊖Ks)/Km.
As mentioned, Km itself needs to be protected. Km is encrypted using an encryption method denoted as E(Km), and the decryption can be denoted D, so that D(E(Km))=Km.
In order to satisfy that Km is never inside the computing environment (in its plain, unencrypted form), the encryption E is applied before Km enters the computing environment. Thus, Km is never in the computing environment, rather only E(Km) is.
In order for Km to be used to protect Ks, it is necessary to select E, D, ⊖, and / such that:
E(Km)⊖E(Ks)=E(Km⊖Ks) Equation 2a,
and D(Km⊖Ks)=D(Km)⊖D(Ks) Equation 2b.
Equations 2a and 2b are referred to as the “homomorphic” property of the method. Note that such a homomorphic property implies that ⊖ may be applied to Ks even while Km and Ks are in an encrypted form, encrypted by E. Therefore, the requirement of protecting Ks with Km, without ever knowing Km, is satisfied—only the “homomorphic encryption” of the master key is known in the system, never the master key itself.
Similar relations may be defined for the inverse operator “/” in order for the “unblinding” of Ks (i.e., the decryption in relation to the blinding with ⊖) to be performed even while both Km and Ks are encrypted with E. The technique of protecting the master key Km while allowing Km to be used is referred to as “homomorphic key encryption.”
Another way to protect master key Km is to apply the blinding operation ⊖ to Km itself as follows.
r⊖K
m Equation 3,
in which r is some suitable value. We will sometimes use a random value r in such a blinding, so this would be called a “random blinding.” In some embodiments of the present invention, a combination of random blinding and homomorphic key encryption is employed.
Generalizing such an approach, different entities (i.e., appliances) in the system may use different encryption (e.g., E1, E2, . . . ) to protect the master key. Such a feature practically means that stealing the encrypted form from one entity will not help a thief anywhere else in the system. The homomorphic property is therefore generalized as:
E
k(Km)⊖Ek(Ks)=Ek(Km⊖Ks) Equation 4a,
and Dk(Km⊖Ks)=Dk(Km)⊖Dk(Ks) Equation 4b,
with similar relations defined for the inverse “/” operator. Thus, the methodology enables:
Examples of practical choices for E, D, ⊖, and “/” may include:
In the discussion below, the PVKM may be viewed as a “location” (whether physical or virtual) in such an environment, while each appliance and other security element may be viewed as another “location” (whether physical or virtual). However, for the avoidance of doubt, the PVKM itself may be implemented as a collection or a cluster; we will still refer to it as a location for the sake of simplicity.
Referring to the drawings, In
It is noted that appliance A is intended to be a simplified example of a plurality of appliances in order to provide clarity in the description. It is understood that the present invention has broader applicability to a collection or cluster of such appliances. Furthermore, PVKM B is intended to be one conceptual entity (e.g., a server); however, in practical implementations, PVKM B may be a plurality of entities (e.g., a cluster of servers for fail-over protection). In generalizations of this approach, there may be more locations, and therefore more timelines (as in
Moreover, the overall processes have been classified into sub-processes: a Sub-Process I for creating a new appliance (for
As stated above, it is desired to generate and use a master key without such keys ever being known (i.e., ever being decrypted) in the computing system.
A random r is generated, and used to blind Km, via the homomorphic property, by the encryption Ek. Km⊖r can then be stored on PVKM B, which can retrieve and use Km⊖r in subsequent steps (not shown in
Appliance A needs to use Km to blind various secrets in later stages. On the other hand, appliance A needs to store Km in such a way that the value of Km is not known in the computing system—not to the appliance A, not to any other appliance, not to PVKM B, nor to any other entity in the computing system. Such a process is cryptographically strong; indeed, its security can be proven in the semi-honest model.
While the above protocol protects keys and master keys in the semi-honest model, it is desired to protect keys and master keys in the more stringent malicious model as well. In the more stringent malicious model, it cannot be assumed that the appliance is implemented as specified. It is necessary to prove that an attacker is not able to falsify the value r, and choose some value that is convenient for the attacker's malicious purposes. The more stringent protocol forces the following two criteria.
Such embodiments can be proven to be cryptographically strong when implemented in the more stringent “malicious model” (as detailed below in the section entitled, “Deep Mathematical Analysis of Protocols”).
The encrypted form of the master key (Ek(Km) and Ep(Km)) is stored on appliance A (Block Step 48). Ep(Km) is transmitted to PVKM B (Arrow Step 50), which checks if the transmittal is the first instance of the transmittal. If it is the first instance, PVKM B stores A=Ep(Km). Otherwise, PVKM B compares the transmitted value to the stored value for verification (Block Step 52). A random r″ is generated, and used to generate E″ and D″ on appliance A (Block Step 54), which then calculates E″(r″) (Block Step 56), as well as Ek(Km⊖r″)=Ek(Km)⊖Ek(r″), Ep(Km⊖r″)=Ep(Km)⊖Ep(r″), and Ep(r″) (Block Step 58), which are then transmitted to PVKM B (Arrow Step 60).
PVKM B decrypts Ek(Km⊖r″) (Block Step 62). For B=(Km⊖r″), PVKM B verifies S1=S2 in which S1=Ep(B⊖r′) and S2=A⊖Ep(r″)⊖Ep(r′). For a defined notation r=r″⊖r′ and Km⊖r=B⊖r′, PVKM B stores Km⊖r (Block Step 64). PVKM B calculates Ek″(r)=E″(r″)⊖E″(r′) (Block Step 66), and transmits E″(r) to appliance A (Arrow Step 68), which decrypts E″(r) (Block Step 70), and stores r (Block Step 72).
The protocol of
The protocol of
The process starts with creating a new appliance (Sub-Process I) according to the steps of
A random number is generated and stored on PVKM B, which essentially is Ks⊖Km, so Ks is generated only by inference without the value of Ks ever being known to PVKM B (Block Step 86). PVKM B is therefore a key manager that facilitates the generation, storage, and retrieval of secure keys and master keys, while never knowing the values of the keys stored therein—a useful property for a secure key-management system. PVKM B then calculates (Ks⊖Km)÷(Km⊖r)=Ks/r (Block Step 88), and transmits Ks/r to appliance A (Arrow Step 90), which uses Ks/r to encrypt the object by calculating (Ks/r)⊖r=Ks (Block Step 92).
In accessing an existing object (Sub-Process III), appliance A requests Ks (Block Step 94) by transmitting a request for the ID of Ks (Arrow Step 96). PVKM B retrieves Ks⊖Km (Block Step 98), calculates (Ks⊖Km)÷(Km⊖r)=Ks/r (Block Step 100), and transmits Ks/r to appliance A (Arrow Step 102), which uses Ks/r to decrypt the object by calculating (Ks/r)⊖r=Ks (Block Step 104).
The protocol of
The process starts with creating a new appliance (Sub-Process I) according to the steps of
In retrieving a protected item (the “get” procedure of Sub-Process II), appliance A requests Ks (Block Step 120) by transmitting a request for the ID of Ks (Arrow Step 122). PVKM B retrieves Ks⊖Km (Block Step 124), calculates (Ks⊖Km)÷(Km⊖r)=Ks/r (Block Step 126), and transmits Ks/r to appliance A (Arrow Step 128), which uses Ks/r to decrypt the protected item and check its signature by calculating (Ks/r)⊖r=Ks (Block Step 130).
It is noted that the case of
The process starts with creating a new appliance (Sub-Process I) from a signed image, for example; at this stage such a new appliance is untrusted. A random r″ is generated (Block Step 140) on a trusted appliance A2, and trusted appliance A2 repeats Steps 58-64 of
PVKM B then generates key-pair Ej, Dj (Block Step 142), calculates Ej(Km⊖r) (Block Step 144), and transmits r′, Ej, and Ej(Km⊖r) to trusted appliance A2 (Arrow Step 146). Trusted appliance A2 then calculates r=r″⊖r′ (Block Step 148), and acts as a “pass-through” entity (Block Step 150) by transmitting r, Ej, Ep(Km), and Ej(Km⊖r) to untrusted appliance A3 (Arrow Step 152). Untrusted appliance A3 then stores r, Ej, Ep(Km), and Ej(Km) (Block Step 154), resulting in untrusted appliance A3 becoming a new trusted appliance.
The protocol of
The protocol of
Trusted appliance A2 and PVKM B then cooperate to provision the new appliance (untrusted appliance A3) with appropriate values that would allow untrusted appliance A3 to participate in similar protocols (e.g., any of the protocols of
Deep Mathematical Analysis of Protocols
Through block-diagram embodiments, described above are protocols referred to herein as Homomorphic Key Management (HKM). Additional embodiments are now treated that are open to a rigorous proof of their security. Described below is how the Homomorphic Key Management (HKM) protocol is secured against active attacks assuming the malicious model. Security under the stringent malicious model is achieved by using coin-tossing and honest-verifier zero-knowledge proofs of knowledge of discrete logarithms.
The HKM protocol involves the following three entities:
The user holds a master key, which is used jointly with the appliance and PVKM key-shares to reconstruct specific keys for data encryption. The role of the PVKM is to assist the appliance in key management without knowing master keys or specific keys, and to enable different instances of the appliance to consistently reconstruct specific keys by combining corresponding key-shares. The specific keys are then used to encrypt various storage objects such as individual files. The protocol's objectives are:
The original version of the HKM protocol assumed that the PVKM and appliance are “passive” (also referred to herein as “semi-honest”) in the sense that the entities follow the prescribed protocol; whereas, an eavesdropper was allowed to be “active,” which means that beyond eavesdropping it could also try to modify and/or omit messages. Security with respect to the PVKM and appliances was achieved by protocol configuration, and security against the active eavesdropper was achieved using standardized tools such as SSL (assuming that a trusted public-key infrastructure is set up and available).
In the active “malicious” model, an additively-homomorphic variant of ElGamal is employed. Specifically, the plain-text space of the encryption is Zq, and a message mεZq is represented by gmεG. The functionality of the protocol does not require actual knowledge of m (for the purpose of key derivation the value gm suffices).
In order to achieve a protocol resilient to “active” adversarial behavior of both the PVKM and various appliance instances, a mathematical description of the various modes of operation of the actively-secure HKM protocol, along with corresponding proofs of security, is provided. The proofs are established based on clearly-stated and well-defined assumptions on the setup of the system (such as the extent to which the cloud provider has access to the data used by the appliance, and the extent to which the Javascript code sent by the PVKM to the user in the setup phase is authentic), as well as based on the security of the underlying cryptographic primitives (such as ElGamal encryption and SSL).
The present protocol provides:
In addition to the use of ElGamal as an encryption scheme, the actively-secure HKM protocol also uses ElGamal as a commitment scheme (in the setup phase between the PVKM and the user). Such a configuration requires in particular the existence of a public-key that was sampled in a way that does not reveal the corresponding secret key to the receiver.
The encoding of plain-texts in the encryption scheme of ElGamal is provided as well. Rather than viewing such encodings as elements in the underlying group, such encodings are viewed as exponents of an appropriately-chosen generator of the group. This allows compatibility between the ElGamal encryption and commitment schemes, as well as opens up the possibility of t-wise independent blinding of the master key.
The implications of the HKM protocol to being secure against active “malicious” adversaries are:
The above holds true as long as one of either the PVKM or the appliance runs honestly. In particular, the protocol is configured to detect any deviation from the prescribed behavior (effectively reducing its security to the semi-honest case). It should be noted that the protocol also assumes that a trusted setup phase, in which the Javascript code runs on the User's side (by the PVKM), follows the specification. However, beyond such a trusted setup phase, there is no assumption on the honest behavior of the parties.
The security of the active HKM protocol relies on the semantic security of ElGamal encryption/commitment with key size k=2048, which is a standard and relatively safe assumption. Functionality of the protocol builds on the (multiplicative) homomorphic properties of ElGamal encryption. Such properties hold true unconditionally, and enable the management and derivation of keys in a consistent manner. To make the protocol non-interactive, challenges are generated offline using a “random oracle” (e.g., SHA-1, SHA-2, and SHA-256) in accordance with the Fiat-Shamir paradigm.
Authenticity and secrecy of communication of messages is obtained using SSL, which means that a trusted PKI has to be in place. Again, the assumption that SSL is secure is standard and relatively safe (provided that the implementation is proper).
The ElGamal encryption scheme works as follows. The key-generation algorithm Gen(1k) generates secret key sk=x and public key pk=(G,g,h=gx), where g is a randomly chosen generator of a group G of prime order q with |q|=k, and x is randomly chosen in Zq. The identity element of G is denoted by iG.
The plain-text space is modified to Zq as described above, the randomness space is Zq, and the cipher-text space is G. G is required to be a group in which it is easy to determine membership, compute the binary operations, and assume that the parties check that cipher-texts are valid by verifying that the cipher-text is an element in G.
To encrypt a value mεG, the sender picks randomness r←Zq and computes the cipher-text (c, d)=(gr, hr, gm). Encpk(m; r) denotes the encryption of a value mεG using randomness r. Note that the cipher-text uniquely determines the value of m. This is because the mapping from rεZq to the values gr and hr is injective, and similarly so is the mapping from mεZq to gm. Given a cipher-text (c, d), the receiver can use sk=x in order to compute d/c=((gx)r·gm)/(gr)x=gm.
Strictly speaking, computing m from gm is considered infeasible, since it requires finding the discrete logarithm of gm. However, as mentioned above, this is of no concern in our application, since for the purpose of deriving keys it is sufficient to learn the value of gm (which is random under the assumption that m is chosen at random).
The security of the ElGamal encryption scheme is equivalent to the Decisional Diffie-Hellman assumption in G, which states that it is infeasible to distinguish triplets of the form (ga, gb, gab)) from triplets of the form ga, gb, and gc, where a, b, and c are uniformly chosen in Zq. Under this assumption, it can be shown that for any message mεG, the distribution Enc(m; r) of encryptions of m (over a random choice of r) cannot be feasibly distinguished from the distribution of encryptions of a uniformly chosen message m0εG.
ElGamal encryption is additively homomorphic (in Zq). For all m, m0εZq, and r, r0εZq, Encpk(m; r) is:
Enc
pk
k(m0;r0)=Encpk(m+m0;r+r0),
where for c, d, c0, d0εG, the value (c, d) (c0,d0) is defined as (c·c0, d·d0).
The ElGamal encryption scheme can be easily converted into a string commitment scheme for messages mεZq. The essential difference between encryption and commitment is that, in the latter case, the receiver is not supposed to be able to decrypt the message m (nor the value gm) by himself, but can do so given “decommitment” information sent by the sender.
To prevent the receiver from learning the secret key, the public key pk can be sampled from a common random string, and it is easy to verify that pk is a valid public key. Alternatively, it is possible to have the sender and receiver jointly sample pk using a coin-tossing protocol. This guarantees that the encryption is semantically secure against both parties, provided that they use a p for which it is possible to generate groups in which the discrete logarithm problem is hard.
Just as in the case of encryption, the message space of the ElGamal commitment is Zq, the randomness space is Zq, and the commitment space is G. G is required to be a group in which it is easy to determine membership, compute the binary operations, and assume that the parties check that commitments are valid by verifying that the commitment is an element in G.
The commitment operation is identical to the encryption operation: to commit to mεZq, the sender picks randomness r←Zq, and computes the commitment (c, d)=(gr, hr·gm). Compk(m; r) denotes the commitment of a value mεG using randomness r. Note that the commitment is perfectly binding (i.e., uniquely determines the value of m). This is because the mapping from rεZq to the values gr and hr is injective, and so is the mapping from mεZq to gm. To decommit a commitment (c, d) to a message m, the sender simply sends over the randomness r along with m. The receiver then verifies the equalities: c=gr and d/hr=gm.
The hiding property of the ElGamal commitment scheme follows from semantic security of ElGamal encryption. In particular, under the DDH assumption, it can be shown that for any message mεZq, the distribution Com(m; r) of commitments of m (over a random r) cannot be feasibly distinguished from the distribution of commitments of a uniformly-chosen message m0εZq.
Just as with the ElGamal encryption, the ElGamal commitment described above is additively homomorphic (in Zq). Note that knowledge of the secret key xεZq, which corresponds to a public key pk=(G,g,h=gx), enables the receiver to retrieve the value gmεG from a commitment (c, d)=(gr, hr·gm). Such a property is useful in the configuration framework of the actively-secure version of the HKM protocol.
There are standard techniques for proving knowledge of the opening to an ElGamal committed value. This can be done in three iterations, costs little in terms of communication and computation, and can be made non-interactive using the Fiat-Shamir transformation.
Given G is a multiplicative group of order q, and given g and h are two generators of G, the input is an ElGamal commitment (c, d)=(gr, hr·gm)εG×G to mεZq. The “prover” claims that he knows the values of r and m. The following three-move, public coin, perfect SHVZK protocol practically coincides with Schnorr's well-known proof of knowledge of discrete logarithms (see Schnorr, “Efficient Identification and Signatures for Smart Cards,” CRYPTO, 1989, pp. 239-252).
It can be seen that the above protocol is complete. Given a challenge a, the prover, knowing s, t, r, and m can compute u=α·r+s and v=α·m+t. On the other hand, if it is indeed the case that c=hrgm, the verifier, knowing a, b, c, d, u, v, h, g, and α, is able to verify that g″=a·cα and hu=(b·dα)/gv. The protocol also satisfies special “soundness.” Given a pair of accepting answers (u, v) and (u0,v0) to corresponding challenges α and α0, one can recover the values r and m used by the prover as “witnesses.”
In addition to the above, the protocol is honest-verifier zero-knowledge. Given a value α←Zq, it is possible to generate values a, b, u, and v which are identically distributed (jointly with α) to values that would have been chosen by an honest prover in the protocol.
The group in use for both the ElGamal encryption and commitment is G=QRp, the group of quadratic residues mod p, where the prime p and a corresponding generator g are sampled once and for all. The prime p is sampled under the condition that it is of the form 2q+1 for a random prime number qεN of size k=2048. The sampling proceeds by randomly picking numbers qi until the conditions that “qi is prime” and “pi=2qi+1 is prime” are both satisfied. A generator gεZ*p of order q is obtained by sampling a random number in Z*p, squaring it, and testing that the result is not 1. Since q is prime and p=2q+1, this guarantees that the order of g is q, and that g generates G=QRp (note that the plain-text space is also QRp).
Since p and g are fixed, whenever it is clear from the context, the protocol derivation refrains from explicitly specifying p and g as part of a public key of the ElGamal encryption/commitment. Thus, to specify a public key pk, it is sufficient to provide a single value h=gxεQRp. In such a case, the corresponding public key is pk=(G, g, h).
In accordance with the HKDF RFC 5869 key-derivation standard (see Eronen and Krawczyk, “RFC 5869—HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” http://tools.ietf.org/html/rfc5869, 2010), specific keys are derived from elements SjεG by computing HKDF(Sj), which yields a 256-bit pseudo-random string (2048 bits of entropy should be more than sufficient for pseudo-randomness) to be used as a key for AES-256 encryption.
Active versions of the main protocols of the HKM system are: Master-Key Commitment (MKC), New Appliance Instance (NAI), Vouched Appliance Instance (VAI), New Storage Object (NSO), and Set Protected Item (SPI)/Get Protected Item (GPI.
The main protocol, NAI, involves setting up the first instance of the appliance in the project, with the assistance of the user, who holds the master key and the PVKM module, which aids in maintaining state (and specifically the various encryption keys) across different instances. The MKC phase involves interaction between the user, the PVKM, and the first appliance instance. The objective of the MKC phase is to allow the user to send the PVKM a commitment to her master key. The VAI protocol allows for the creation of a new appliance instance that is “vouched” for by a “trusted” appliance instance (i.e., one that has been set up by the NAI protocol). The purpose of the VAI is identical to that of any appliance. However, unlike the case of a trusted appliance instance, there is no requirement to trust its execution.
Another important protocol, NSO, enables the creation of a new specific key to be used to encrypt data (e.g., on a storage device), and allows the PVKM to store a “blinded” version of this specific key for future use. A related protocol, SPI, enables the appliance to generate specific keys “on the fly,” and to transmit a “blinded” version to the PVKM. The GPI protocol allows an appliance to retrieve specific keys on demand.
Given nεN denotes the total number of appliance instances, and mεN denotes the total number of specific keys, the security parameter is denoted as kεN. It is assumed that the traffic between the parties is encrypted and authenticated using SSL. It is further assumed that the user possesses a master key, KεG, which is used throughout the life of the system (in particular across different instances) in order to generate, and then reconstruct, specific keys. Capital letters (such as K and Si) are used to denote keys, and letters from the Greek alphabet (such as αi, βi, γi, and δi) are used to denote “masks” that are used for blinding the keys.
The MKC protocol is in effect a setup phase in which the user commits its master key KεG to the PVKM. This commitment is subsequently used by the PVKM to verify that a given instance of the appliance faithfully follows the protocol. The commitment is required to be hidden from the PVKM. To this end, it is assumed that its public key is sampled in a way that does not allow the PVKM to know its corresponding secret key. It is also assumed that the PVKM does not share this commitment with any other party (most importantly, with any appliance instance).
Since the user is running JavaScript code that is determined by the PVKM, the correct execution of the setup phase necessitates trusting the PVKM to send the intended code. Without this assumption, the PVKM could simply have the user violate the “hiding” property of the commitment (e.g., by sending the user code that causes it to reveal the master key to the PVKM). The value of r is used subsequently when setting up a NAI, and when vouching for subsequent appliance instances.
To initiate a NAI, the system uses a three-party protocol between the user (denoted as U), the first instance of the appliance (denoted as A), and the PVKM server (denoted as P). The protocol does not require communication between U and P. Its security crucially relies on the following three assumptions.
The user U initiates the first appliance instance, A. The appliance is ephemeral and resides in a compute cloud (i.e., a cloud used for computing), such as an Infrastructure-as-a-Service (IAAS) environment. It can be later used to interact with P in order to reconstruct specific keys, SjεG, even if these keys were generated by other instances of the appliance. It is also used later to spawn subsequent (and untrusted) appliance instances, Ai. The way in which the state is maintained between different instances of the appliance is by having U consistently use the same master key K in all instances Ai, and by having P store a “masked” version of the specific keys Sj·K (to aid preserving secrecy against the PVKM).
A : Prove knowledge of γ and
P: Prove knowledge of ~γ and r
Intuitively, the secrecy of the master key K with respect to A is guaranteed by the assumed security of the ElGamal encryption scheme (note that sk is not known to A). The secrecy of K with respect to P is guaranteed by the fact that the value ˜γ is chosen uniformly at random, and is not known to P (the only value that P learns is gK−γ
Note that once P learns the pair (gr, hcomr·g−γ
Finally note that A is able to compute δ=γ+γ˜. This is because, by the end of the protocol, A knows both γ (which is sent to A by P) and of ˜γ (which is sampled by A). Also, note that P is able to compute the value of gK+δ. This is because P knows both gK+γ
The VAI protocol generates a new appliance vouched for by a previously-generated appliance. The protocol requires the active participation of a new appliance instance Ai, a previously-initiated appliance instance Aj for j<i (this could either be the first appliance instance or subsequent instances), and of the PVKM P.
Ai: Prove knowledge of γi and si
Ai: Prove knowledge of δj and ti
P: Prove knowledge of ~γi and r
As in the case of the NAI protocol, once P learns the pair (gr, hcomr·g−γ
Also note that Ai is able to compute δi=γi+γ˜i. This is because, by the end of the protocol, Ai knows both γi (which is sent by P) and ˜γi (which is sampled by Ai). Also note that P is able to compute gK+δ
For the NSO protocol, once an “instance-specific” masking gK+δ
The string Sj output by Ai is by definition the jth specific key Sj. Since the value αj that is locally stored by P satisfies gαj=gK·Sj, and since gK is random and secret with respect to P (it is only known by U), presumably Sj is secret with respect to P.
However, it should be noted that this secrecy is not perfect, as P will eventually hold an entire sequence gK·S1, gK·S2, . . . , gK·Sm of specific keys that are “blinded” using the same master key K. This in particular means that P can potentially infer various relations between the keys (such as the ratio Sj/Sj0 for j, j0), and “opens the door” for related key attacks. This is in practice mitigated by applying a “random oracle” to the keys. Specifically, the actual data-encryption keys are derived from Sj's use of the HKDF function (see Eronen and Krawczyk cited above), which is assumed to behave as a random oracle.
In the SPI protocol, the appliance Ai will want in some cases to generate a specific key, Sj, “on the fly.” After having generated the key, the appliance transmits the key (“blinded” with the master key K) to the PVKM for future use. The SPI protocol proceeds as follows.
As before, the string Sj output by Ai is, by definition, the jth specific key Sj. Since the value gαj that is locally stored by P equals gK·Sj, and since gK is random and secret with respect to P (it is only known by U), presumably Sj is secret with respect to P. However, as in the previous case, secrecy is not perfect due to the various relations between the keys.
In the GPI protocol, the ith instance of the Appliance, Ai, can retrieve the jth specific key, Sj, on demand for decrypting storage objects. This is done by having Ai interact with the PVKM (which stores “blinded” versions of the specific keys).
Employing t-wise independent blinding, one can strengthen the protection against related key attacks by having the master key be a degree-t polynomial K(x)=Pti=0kixi. Then, the specific keys Sj are blinded with gK(j). The main observation is that it is possible to homomorphically evaluate the encryption of gK(j) given j and encryptions of gk0, gk1, . . . , gkt. This is because gK(j) equals g raised to the power of Σti=0kiji, which equals:
Πi=1t of ((gk
The benefit of blinding with a degree-t polynomial K(x) is that the distribution K(1), . . . , K(m) is t-wise independent. This means that P is not be able to infer relations amongst any subset of t-specific keys, Sj1, . . . , Sjt. Thus, the complexity of P mounting a related key attack is significantly increased (since P could only rely on relations between t+1 and more keys, thereby mitigating relations between any t or less keys). In practice, taking t=2 should suffice, since related-key attacks usually rely on binary relations amongst the keys.
While the present invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications, and other applications of the present invention may be made.
This patent application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/992,935, filed May 14, 2014, which is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61992935 | May 2014 | US |