MXPA01004303A - Incorporating shared randomness into distributed cryptography - Google Patents

Abstract

A method of distributed cryptography for high consequence security systems which employs randomness between operating parties. Shared randomness is accomplished by sharing cryptographic keys stored in secure hardware tokens by potentially less secure software or general purpose computing units that perform distributed cryptography. The shared randomness is based on shared keys (at the tokens) and unique context. Shared random values are incorporated into the computation of partial results used in the distributed cryptographic calculation. The incorporation of shared randomness provides a hand-shake among the hardware tokens. When the operation is successful, a result is computed with assurance that the correct parties have taken part in forming the result. The hand-shake assures binding of operating parties and added system security.

Description

INCORPORATION OF SHARED RANDOMIZATION IN DISTRIBUTED CRYPTOGRAPHY The invention relates to the field of electronics and data processing, and in particular to methods and apparatus for distributed cryptography incorporating shared randomness.

BACKGROUND OF THE INVENTION Distributed cryptography is related to cryptographic services that are distributed among different parties, so that a plurality of parties must perform an action to carry out an act. For example, a cryptographic function can be re-rendered as distributed fragments. When an entry is made, the parties that possess the fragments must present themselves with a quorum of themselves, and each member of the quorum activates their fragment at the entrance, which causes a partial result for each member of the quorum. The partial results are combined into a final result that correctly represents a cryptographic function, such as description, signature, or any other function. More particularly, the function may be based, for example, on a discrete logarithm in a first field or another domain or functions based on processing difficulty.

A shared cryptographic function provides a service that has integrated distributed reliability. In distributed reliability services that use shared cryptographic functions, the service operation almost always presents itself as a single, coherent element that is centrally controlled to achieve a uniquely identified sensitive function. The service has decentralized control for security against its own members and for geographical distribution and / or organizational reliability. The shared cryptographic functions support cryptographic services, such as certification authority and key custody. The needs of cutting-edge technology impose more rigid operational and security constraints than those present in existing systems. These constraints have forced the integration of various technological components, thus introducing more complicated workflow relationships. These workflow relationships tend to be more complicated than the input-output relationships and may require more than just careful access control mechanisms. In sophisticated security systems that are not isolated, one can not rely on the software modules, operation systems and physical security. Often, secure hardware tokens are included in sophisticated security systems to improve security protection. As an alternative, cryptographic modules, for example, co-processors, may be added, as well as other cryptographic facilities, for example, hardware or software. The hardware tokens are found under the software of the general-purpose computing units. In this way, the hardware units do not communicate with each other directly. Hardware tokens are the "most protected" system components, and therefore the most reliable elements of sophisticated security systems. To ensure security "side by side" at the highest level, hardware tokens must provide security for themselves. Said explicit security seems to require an explicit "exchange of control codes" between the components, that is, the hardware tokens. However, the explicit "exchange of control codes" overloads the workflow adding interactions, reduces performance, and adds to the necessary functionality by requiring multiple mutual parts authentication of the limited computing environment in the hardware tokens. The following references provide additional background to the invention and are incorporated herein by reference. 15 [A] R.J. Anderson, Why Cryptosystems Fail, Proceedings of the First Annual ACM Conference on Computer and Communications Security, CCS '93. [B] R. Blakley, Safeguarding Cryptographic Keys, FIPS Con. Proc (v. 48), 1979, p. 313-317. [BF97] D. Boneh and M Franklin, Efficient Generation of Shared RSA Keys, Crypto 97 proceedings. [BDL] D. Etoneh, R. DeMilo and R. Lipton, On the Importance of Checking Cryptographic Protocols for Faults, Eurocrypt 97. -ßáriUü.

[B88] C. Boyd, Digital Multisignatures, IMA Conference on Cryptography and Coding, Claredon Press, 241-246, (Eds. H. Baker and F. Piper); 1989. [BGS] J. Bull, L. Gong and K. Sollins, Towards Security in an Open Systems Federation, Esorics 92. [DDFY] A. De Santis, Y. Desmedt, Y. Frankel, and M. Yung, How to Share a Function Securely, ACM STOC '94, pp. 522-533. [DF89] Y. Desmedt and Y. Frankel, Threshold cryptosystems, Advences n Cryptology-Crypto '97, pp. 307-315. Springer-Verlag. [DF91] Y. Desmedt and Y. Frankel, Shared Generation of Authenticators and Signatures, Advances in Cryptology-Crypto '91, pp. 457-469. Springer-Verlag.

[DH] W. Diffie and M. Hellman, New Directions in Cryptography, IEEE Trans. on Information Theory 22 (6), 1976, pp. 644-654. [FIPS140] FIPS 140-1, Security requirements for cryptographic modules, National Institute of Standards and Technology, January 1, 1994. (See also http://csrc.nist.gov/fips/). [F89] Y. Frankel, A practical protocol for large group oriented networks, In J.J.

Quisquater and J. Vandewalle, editor, Advances in Cryptology, Proc. Of Eurocrypt '89, (Lecture Notes in Computer Science 773), Springer-Verlag, pp. 56-61. [FGMY] Y. Frankel, P. Gemmel, P. Mackenzie and M. Yung. Proactive RSA, crypto 97. [FGMY2] Y. Frankel, P. Gemmel, P. MacKenzie and M. Yung. Optimal Resilient Proactive Public-Key Systems, FOCS 97.

[FGY] Y. Frankel, P. Gemmel and M. Yung, Witness Based Cryptographic Program Checking and Robust Function Sharing. STOC96, PP. 499-508. [FMY] Y. Frankel, P. MacKenzie and M. Yung. Robust Distributed Efficient RSA-key Generation, manuscript. [GJKR] R. Gennaro, S. Jarecki, H. Krawczyk, T. Rabin, Robust Threshold RSA, Crypto96, pp. 157-172. [GGM] O. Goldreich, S. Goldwasser and S Micali, How to construct random fuctions, J. Comm. Sci. 28 (1984), pp. 270-299. [HJJKY] A. Herzberg, M. Jakobsson, S. Jarecki, H. Krawczyk, M. Yung, Proactive Public-Key and Signature Schemes Proceedings of the Fourth Annual ACM Conference on Computer and Communications Security, CCS'97.

[JA] M. Joseph, and A. Avizienis, A Fault-Tolerance Approach to Computer Viruses, IEEE Sym. on Security and Privacy, 1988, pp. 52-58. [K] R. Kocker, Timing Attacks on Implementations of Diffie-Hellman, RSA.DSA and Other Systems, Crypto96. [M] S.M. Matyas, Key processing with control vectors, Journal of Cryptology, 3 (2), pp. 113-136, 1991. [MT93] R. Molva and E. Tsudik, Authentication Methods with Impersonal Token Cards, IEEE Sym. on Security and Privacy, 1993, pp. 56-65. [O Y] R. Ostrovsky and M. Yung, How to withstand mobile virus attacks, Proc. Of the 10th ACM Symposium on the Principles of Distributed Computing, 1991, pp. 51-61.

[RFLW] M. Reiter, M. K. Frankiin, J. B. Lacy and R. N. Wright, The O Key Management Service Proceedings of the Third Annual ACM Conference on Computer and Communications Security, CCS'97. [RSA] R. Rivest, A. Shamir and L. Adleman, A method for Obtaining Digital Signature and Public Key Cryptosystems, Comm. of ACM, 21 (1978), pp. 120-126. [Sh] To Shamir, How to share a secret, Comm. Of ACM, 22 (1979), pp. 612-613. [R] T. Rabin, A simplified approach to Threshold and Proactive RSA, Proceedings of Crypto 98, Spriner-Verlag, 1998, p. 89-104. [Y94] B. Yee, Using Secure Coprocessors, Ph. D. Thesis, Carnegie Mellon University, Computer Science Tech. Report CMU-CS-94-149, May 1994.

BRIEF DESCRIPTION OF THE INVENTION The present invention develops cryptographic mechanisms for security systems of high importance that employ shared randomness between the operating parts. The use of shared randomness and the incorporation of randomness in a distributed cryptographic operation allows security side by side through hardware components without communication within the sophisticated security system. Shared randomization can be carried out with the common use of a cryptographic key stored in secure hardware tokens that are housed in potentially less secure software and / or general-purpose computing units, that carry out a distributed cryptography (for example, signature service by distributed RSA). Shared randomness is integrated into the computation of partial results in a distributed cryptography system. The integration of the shared randomness in the partial results achieves an exchange of control indicators between the witnesses. Mainly, when the operation is successful, a result is computed with the assurance that the correct parties have intervened in the computation. This ensures the link of the operation parts, and especially the added randomness added is security added to the system. The workload is balanced between the witness and his employer. In a preferred embodiment of the invention, a method of distributed use of cryptographic keys among a plurality of distributed electronic devices is developed, in which distributed electronic devices can communicate with a central server to develop a cryptographic output using shared random values. The method includes the steps of: (a) computing shared values in a known and agreed context; (b) generate random values using the shared values; (c) generate a partial result for each device using the random values; (d) compute an output based on the partial result.

BRIEF DESCRIPTION OF THE DRAWING The present invention will be described below with reference to the accompanying drawing wherein: Figure 1 is a block diagram illustrating the horizontal separation of the distributed cryptographic service architecture.

BRIEF DESCRIPTION OF THE PREFERRED MODALITIES To achieve reliability between the hardware components, a hardware-to-hardware interaction "side by side" can be used, which does not only reside in non-hardware components. The exchanges of control codes and mutual trust can help in distributed systems to provide mutual checks that increase system integrity, availability and security [A, BGS]. When the hardware components are not directly connected, these exchanges of control codes can not be carried out directly. An indirect implicit verification of hardware units is necessary that complies with the vertical and horizontal separations of the architecture that does not consume resources. An "indirect and implicit control indicative exchange" through servers and the software units that connect them is possible using a new primitive. The operation that uses the new primitive will ensure high level "side by side" reliability while maintaining the vertical layers. New algorithms and secure protocols achieve mutual multiple part reliability at the management level. The side-by-side security that uses the new primitive does not require the secure hardware token and can provide security side by side in the divisional units. In general, a sophisticated security system can be built with an increase in computational needs. The hardware and software units can be added at a relatively marginal additional cost. The use of hardware is not so evident when there is a concern for efficiency, because security hardware is almost always slow; that is, hardware tokens are often already a "old generation" computing device by the time they are certified. In addition, not all hardware devices have accelerator chips for large enough computing (2048-bit RSA accelerator chips are not prevalent today). Security can be reduced by dasing the security parameter, for example, by using a small mixed RSA. A reduced security parameter is unacceptable because opponents generally have state-of-the-art equipment. Therefore, there is a need to balance security protection with performance. It is necessary a barter between the hardware that makes part of the computation and the software unit of the computational device (for example, a PC) that does the rest. In general, for sophisticated security, additional computation must be tolerated (since the budget allows adding additional computing devices). This additional computation should not be done in the safe hardware cost control layer. The methodology described here balances the concerns for computational efficiency. Shared randomness is achieved between two or more entities by sharing a common key and applying a pseudorandom function or a pseudorandom number generator to generate a value that is common among entities. The methods for sharing keys, the pseudo-random functions and the pseudo-random number generators are procedures and notions that are known to those skilled in the art. As an example, the shared randomization methodology is applied to cryptographic calculations using the RSA algorithm. The RSA key generator produces two large random prime numbers p and p2 and computes n - pi p2 mixed and the fi function Euler f (n) = (p? -1) (p2-1). To determine the st key, the generator chooses a random number of, so gcd (c, f (n)) = 1. The public key is n and e, so ed = 1 (mod f (n)). The direction of a (difficult) sense of RSA (used in the description or signature of a message m) is Sm = md (mod n), while the public address (easy) (used in encryptions and verification of signature) is (Sm) e (mod n) that returns to m. The RSA function is a building block for many security systems where the adversary is allowed to have initial access to the system and obtain results based on various restrictions on entry, that is, encryption of only selected text, only random text that goes sign, etc. Two types of separations of system elements are distinguished: Horizontal and Vertical. 5 The horizontal modules divide the architecture into divisional units with separate "domains of reliability". The domains are derived from the organizational structure, which can be defined through the business structure, contracts, geography, security policy, etc. This structure defines the top layer that enforces the policy Organizational (reliability relationships) and preferably fits within the existing management workflow. The vertical components divide the architecture into layers of technology limits: network interfaces, firewall walls in networks and access control gates, operating systems, software application, and hardware tokens (as an example of a reliable device). Other components, such as humans (operator authorization), physical security, and ancillary and administration systems, such as logging, tracking, secure synchronization, and recovery can be added. Another explanation about the context of the key management system of software Or can be found in [RFLW]. The combination of the horizontal and vertical components in a work architecture involves two basic design aspects - separations and links. The separations are divided horizontally into i ^ Hitt-ajs | iíjiiÉ¿A? divisional (organizational) modules and vertically in components in a divisional module. The links ensure uniform collaboration between authorized elements, only horizontally and vertically. The described link method minimizes security exposure and preserves the integrity of the cryptographic service. Figure 1 is an example of the workflow of the horizontal module. An applicant for cryptographic service 104 is one or more entities that issue requests to centralized management (eg, defined by the organizational structure) requesting the cryptographic service. First, the request is sent to server 108. This request, for example, may be to issue the signature of the organization in a specific message or text description coded with spy connection. To protect against various attacks (for example, man in the middle), cryptographic service requests are authenticated, usually with the signature or similar of the requestor. This is analogous to a bottom-up request in a mandatory integrity policy model. The server 108 transmits the request on an authenticated channel 112 to the divisional units 110 and can also first negotiate which divisional units will participate in the execution of the cryptographic service (ensuring the availability and / or management of the load balancing at the divisional unit level) . After verifying the validity of the request for the cryptographic service and based on its specific security policy, the divisional units 110 perform a computation based on the information in the request for the cryptographic service and private information. The divisional units 110 then transmit the output on an authenticated channel 112 to the server 108. When all the necessary divisional units respond, the server 108 can complete the requested cryptographic service. Then, the server 108 will provide the result to the requestor 104, either flat or, if security is required, e.g., a description service, encrypted under the applicant's key. Divisional units 110 have an integrated redundancy when the number of divisional units required to perform the service is less than the total number of divisional units. Servers and cryptographic service requesters can be added to the system if high availability is required. Various maintenance procedures can be executed internally in the system, for example, a secure time synchronization. The horizontal units in the present example jointly carry out the signature by RSA. Said distributed signature has been shown to be possible by algorithm (at a certain level of distribution or other) [B88, F89, DF91, DDFY, FGY, GJKR, FGMY, FGMY2]. An organization (centralized management), which externally is an entity, has a public signature key by RSA; PK. The cryptographic objective of a system of common use of function by distributed RSA is to divide the signature capacity by RSA so that any / more units corresponding to divisional units can sign a message that can be verified by PKEven an adversary, at most with divisional units, can not sign. This is the same protection as in the secret common use [B1, Sh], but in this example, the signature operation can be repeated, as long as the key is valid. Analogous to non-digital methods, the security policy and the signature approval structure of the internal organization must often be transparent to external entities. Transparency serves three purposes: (1) external parties prefer not to be complicated by, and generally can not enforce, the policy and practice of the signing party; (2) transparency ensures that external entities maintain independent compatibility of the internal structure and changes in the internal structure; (3) since external entities do not know who or how many individuals "approve", that is, participate, in the signature of the message, the secret of internal organization is preserved, which is very important for certain organizations. The Basic IBM security modules and the Certificate Issuance System (CIS) RSA assume multiple physical keys to control agents to operate the cryptographic unit. The physical keys have electronic keys and other information and must be inserted in the device. In contrast, the present system employs distribution of reliability between remote components that are hidden within different vertical components and do not interact explicitly. Secure hardware tokens provide some additional protection. In fact, current practices (for example in banking and military applications) dictate the use of secure hardware mechanisms to improve security protection. If the hardware tokens do not have their own protected I / O between the user and the hardware token, and most do not, they can not protect against attacks from an operating system and application layers, where the entries " illegal "(without authorization) are submitted to the device. However, they can protect private keys in the long term. Through the use of audit, monitoring, virus detection, intrusion detection, proactive security [OY, HJJKY], etc., an attacker in the software system that is well maintained can have only a short-term effect, which It is acceptable in some areas. The withdrawal or incorporation of shared randomness based on shared keys in computing modifies the original computation by another randomness. With the incorporation of shared randomness in the computation, links are created. The presence of components in computing is assured without further verification. Shared random keys are almost always used for encryption or authentication, but here they are used as computation modifiers. Since they are shared, the modification in some location can count in another location or through computations made in another location.

Shared Randomness Incorporating Secure Distributed, Hardware-Based RSA A first embodiment of the present invention incorporates shared randomization into a secure and hardware-based distributed RSA system. The distributed and secure RSA is optimized using shared random key computation and ensures security in operation, as long as no quorum of the divisional units is committed. The elements signed by the software are allowed to grow in relation to the size of the public key block (/ is the number of units, L = l !, of / are necessary to produce a signature). In the following example there is no distinction between hardware and software. The described protocols are useful when hardware tokens are not incorporated into the architecture. PRF? (-) denotes a pseudo-random function indexed by the key k. Pseudorandom functions are used here by way of example, but other shared key functions may be employed. Preparation: The next preparation of a time is done for shared k values. • Generate an RSA function that has a public key (e, n) and a private key d. • Due to the extended Euclidean algorithm, the distributor can L2 compute P, s ', so 1 = eP + - ¿-s', where H = gcd (e,). The distributor H chooses a random polynomial Aj SR. { 0, L, -, 2L3n2 + et} for 1 < j < t-1 (the polynomial is above a subset of the integers: Z).

• The entity / with public interpolation point x¡ = / receives a secret shadow Si = A (x¡) eZ and the Server receives a public point P. • Each pair of entities (/ ', /) jointly generates a secret key shared to generate shared randomization s, / = s j for the pseudorandom generator. This can be done by exchanging Diffie-Hellman keys [DH] (with added authentication) or some other shared randomization generation technique. The generation of keys and the shared distribution above are based on the co-pending patent application no. 08 / 842,080, filed on April 28, 1997, with the title System and Cryptographic Method of Public, Proactive Keys, of Optimal Elasticity ("Optimal Elasticity") that are incorporated herein in their entirety as a reference. With the use of [BF97] and the co-pending patent application no. 09 / 315,979, filed on May 21, 1999, under the heading Generation of RSA Distributed Keys of Robust Efficiency, which is hereby incorporated by reference in its entirety, a distributor procedure can be employed that is shared between the hardware to produce a distributed reliability of this common use; so it does not reside in any simple entity. Operational phase:? where | ? | = t are the divisional units designated to the participant in the firm (they are available for system management at this point). The management server notifies the members of? what it is ?. The signature is used as an example of incorporation of shared randomization computation, but shared randomization can be used with other cryptographic functions (for example, description). • The entity j computa s' m¿ - Sj- Zj ?? +. { ? go ?. { j} sign (/ - v) -PRFsj, v (m)} where . { j} (x / -xv) "1 (0-xv) • The entity / transmits Smj, A = mSmj," mod ny transmits the result to the merge server • The merge server computes the signature of m, Sm = mp • pve? Sm, v, A mod n. «The combination server can" validate the exchange of implicit control codes "and verify that: (Sm) e? = M (mod n) .The previous protocol produces a secure signature and correct of a message m corresponding to the public key (e, n). The common use of pseudo-random functions between the hardware units and their invocation in computing generates an "exchange of control codes towards t" between the components of the This creates a self-aware property where the absence of a unit is detected, as long as only one original unit is present. The distribution of the computed exponent in the hardware exponent and the software exponent has achieved a balance between hardware and software, as described below. In addition, the common use of pseudo-random functions allows the protocol to be non-interactive, where the previous practical scheme of this nature required initial interaction to exchange the true random bits. A balance between the opponent's efficiency and placing (attacks) is provided incorporating shared randomness. The commitment of the software and the commitment of the hardware is distinguished using shared randomness. Another embodiment of the present invention provides a scenario against an adversary attacking a single device; the device is protected against time control attacks (because the exponential time channel is a dependent pseudorandom function, but independent of exponents), as well as attacks by an adversary that makes I / O requests on a single device. A modification of the operational phase allows to distinguish between hardware and software in a divisional unit. Operational phase:? where |? | = f are the divisional units designated to the participant in the signature. Divisional units are available to system management at this point. The management server notifies the members of? What is it ?. The signature is used as an example to incorporate the shared randomization computation, but the randomness shared with other cryptographic functions (for example, description) can be used. • The entity and compute S'mJ = Sj - Zj +. { ? V6A \ wsign < ~ v) 'PRF0 / v (m)} where ZJ, A = p V.? \ { ? (xj -? v) ~ 0 -? v).

• The hardware of entity j provides its software S? .? = m mJ ", r moá n where r can be a string of (pseudo) random bits of length poly (log (/?)) or zero (0) .The use of zero can be preferred depending on hardware constraints. The entity / now transmits SmJ? = Mm ", wJt? Od n based on the input it received from the hardware and transmits the result to the merge server. • The combination server computes the signature of m, Sm = mp pv £? 5m v? mod n. • The server can "validate the exchange of implicit control codes" and verify that: (Sm) e = m (modn). If an adversary has access to t or more of the computing devices, the adversary can sign any message, since he can authorize the signature request to the hardware witnesses. It is assumed that hardware tokens only have I / O interfaces through software controlled devices. A signature interface between the server / requester and the hardware tokens can be included to avoid requests not authorized by the local or divisional unit. This protocol assumes that hardware and software must be compromised in many locations, which is an improvement over an RSA of a single module in which the adversary only has to commit a single computing unit.

Another embodiment of the present invention addresses the situation where the adversary is supposed to break into "almost everything" the system; the adversary has access to the memory of hardware devices v < t and all software units t. This adversary takes over all the software units; consequently, it is necessary to ensure that the software within a hardware token is sufficient to hide the exponent d. This is an extremely strong adversary and it is necessary to make extreme assumptions to provide efficiency and security. It is a plausible assumption that some bits of o * are known to be difficult (difficult to guess, as difficult as finding d) even when the rest of d is known. It is assumed that a fraction of the low order bits of d is difficult. Other assumptions can be faced in an analogous way.

Assumption: For 0 < e < 1, reveal the most important bits of log n- (log n) e does not reveal d. (Note: when e is smaller, the upper half of d is easy to compute) The strategy ¡? () That is applied chooses a random number r on the scale [-l + d, + h £ + d] where d > e, which can force an increase in the domain size from which the exponents are taken. Such an increase is always possible with RSA. h = log n is the security parameter. The protocol can be as efficient as the plausible number of bits that must be hidden; S - - r can be chosen to minimize the multiplication of the hardware token. For example, low Hamming weight (less than a few in the chain) or a short chain (say, half the size of common use). The pseudo-randomness is produced uniformly by means of the devices, for example, using the same function of a single direction based on DES with publicly specific keys, where its performance is independent of the message. Therefore, time control attacks do not apply. Due to the pseudo-randomness, an adversary who sees time control of the hardware device and tries to use the time channel to deduce the permanent common use will fail. The reason for this failure is the combination of the pseudo-randomness, which varies between messages and the random extraction of each exponent that will be made in the hardware. This creates a "random key schedule" in each execution, and in this way frustrates time control attacks.

Robust computations with reduced communication using shared randomness Another embodiment of the present invention provides robust computations with reduced communication using shared randomness. If a server does not work well, there may be no practicable way to determine who acted incorrectly. Treating all subsets of common users until a complete signature is computed is too expensive (for example, finding a subset of size t = 1 + 1 of honest parts of / would be exponential in I). In these cases, the robust threshold RSA, where the combining effort is efficient even when the t parts are adverse, may be required. The robust threshold RSA was first introduced in [FGY, GJKR]. Mainly, the robust threshold RSA provides a secure assembly that can be computed quickly and has the ability to verify information while providing isolation to common users. To verify that a server that acts / e? sent a valid partial result, the following operation is performed with the server /. The shared values added to computations presented here will save approximately half of the communication in the procedure compared to that of the co-pending application no. 08 / 842,080 ("Optimal Elasticity"). • (Preparation of the recovery system) For each / ', the system publishes g, L mod «. • (User preparation i) Generates shared value keys together sz. - sj i s j ... s' j, ¡, (paral <; j = l) with j and publish commitments g "', Jg J, ga ,, Jg¡J where g, gx are of maximum order and the discrete logarithm of gi base g is unknown • For an unsuccessful attempt to sign a message m by?: PRF < »• The entity / 'publishes R .. = gL2S °"' A (gl) * - 'mod n, and U, = pye? (Gl)' where p '(j, v) = -sign (j - v) for j? v and, 1 otherwise. PRF. (m L PFR 0") • The entity i or j publishes ^ j = g" 'J fe1) "3 = ^ (in each pair, only ioj need to publish and the other needs to verify) • A statement of dispute: yes there is a dispute between / and /, then they open their commitments asjj and cfj and one is removed (with a perspective, this removal is even a regeneration for proactivation, as explained below.) • Each server / verifies the transition from poly-use common to sum-common use, mainly that for all / eA \ ß): (51) "1? = U, -, pv £? (??? r, (I ')) where V ^ Tl ^ -x and V2 =? LVEA. { i? x] - xv) • If the verification does not pass, then a dispute resolution is made, and the server / is removed and a new one is chosen? to make the signature. PRF («or • The common / public user Qj = UveA (gl) s, J mod n.) A knowledge test of the discrete logarithm Qi base g1 is performed, as described in [FGMY2]. (In practice , a Fiat-Shamir transferable test may be sufficient based on an "ideal filler") • The use of a robustness algorithm of [FGY] or [GJKR] (for safe cousins), using the witness 8 moa n. If a common user can not do the above, or if he has stopped halfway through the complete protocol, he is eliminated and a new one is used? This operation is done to locate fraudsters if the signature with the common uses of sum went wrong (and with a perspective, as part of the subsequent proactive update). This operation succeeds in removing parts that do not work well. In addition, it allows in the case without failures (for example, all parties are honest and active in a round), a "non-interactive" robustness that verifies the "generation of common uses of sum" (when using the Fiat-Shamir method) . For the added efficiency load, it is recommended that the system be run without robustness test. Only when an appropriate signature fails for a particular message, if the robustness improvements are incorporated to eliminate fraudsters.

Proactive distributed RSA with shared randomness Another embodiment of the present invention relates to a proactive distributed RSA methodology that uses shared randomness. A proactive instrumentation of the communication model is explained in [HJJKY]. Time is divided into periods that are determined by the common global clock (for example, a day, a week, etc.). Each period consists of a brief update phase, during which the servers participate in an interactive update protocol, at the end of which they have new common uses (in fact a new common use) of the secret d. After the update, there is a function computing phase, in which the servers perform the intended secret key operation using their current common use of d in numerous entries. The adversary is linked in a computational way, and can contaminate the servers at any time during a period, viewing the memories of contaminated servers and / or modifying their behavior. A model does not differentiate intentional failures of "normal" server failures (for example, complete failures). However, when an adversary that bursts into a common user is found, it is "removed" (for example, through a restart procedure) before the common user becomes operational. The restart operation is carried out immediately when attacks or deviations of the protocol are detected, and it is exceeded during the update. Within the proactive model, you can allow a period for processors to fail by stopping and then rejoining (failure-stop and meeting). In this way, an unavailable processor is not necessarily considered "defective" in an intended sense. There are several ways of shared randomness that add to the algebraic computations that can help in proactive RSA systems. Fully proactive updated witnesses are possible. In addition to sharing common reuse, pseudo-random functions should be replaced by new ones during updates.

In fact, when pseudo-random functions are updated for the first time, a new shared randomization mechanism must be obtained, but the function itself must remain unchanged. Then the interactions are reduced in the update. The change of representation "poly to sum" and "sum to poly" for the system, as described in copending application 08 / 842,080, can be made. (It should be noted that the last two steps are not necessary). The protocol poly a sum followed by addition to poly based on renewed shared randomness, is a secure protocol with reduction of interaction compared to the original update poly to sum, sum to poly. The total number of servers can change from / to f, and the threshold can be changed from f to f during an update. You can use some dynamic updates that are less expensive. One of those changes is to update the pseudo randomness functions only. This can be done interactively between the parties, for example, using Diffie-Hellman with exchange of authenticated keys between the parties. Since the parties share randomness, they can also perform what is called a contingent key exchange based on the exchange of Diffie-Hellman keys, incorporating shared randomness. As an example, P is a cousin, g is an order generator of major cousins of a subgroup of Zp, and k is a shared random key. The Diffie-Hellman key exchange is A sends to mod mod P and B sends gr "mod P and the key is gab mod P, which can be computed through A and B. The continual Diffie-Hellman key exchange incorporates the shared randomness into the transmissions, ie A and ga + PRF A "- ta and ß send g¿ + PRF ß" 'tag) where tag is an agreement on occasion In a similar way, it is easy to see that gab can be computed by means of A and B, for example B can compute (ga + PRF / (vr 'ia9) I gPRF' ta9) f As soon as the key is used, for example, for encryption it can be determined if both agree on the same key. adding and removing parts dynamically (through an update) With the limitation of the operation to add and remove parts of the recently updated group, proactivation can also be carried out by deciding to use / not use the shared randomness that is being used in common with the parties updated recently This is an access control function that computes keys (analogous to the activation of "control vectors" in DES keys [M]). It ensures that limitations in cooperation can be easily achieved with shared randomness (using shared random values as credentials). Shared random values can be used for key control, for example, monitoring of collaborating parties. This key control can be used to prevent an entity from signing before performing a proactive step. For example, if an adversary has contaminated a server, it is possible to prevent the server from collaborating in a signature before the proactive. While a complete proactive regeneration of cryptographic tools is needed to ensure that past contaminations (memories learned in the past) are forgotten (mainly erased and made irrelevant), "simpler" mechanisms can be used to ensure that future contaminations can not learn the past This is done by regenerating the progress of the keys for shared values. This will facilitate the simulation arguments when the "pseudorandom past" becomes random. This can be achieved by updating the pseudo-randomness based on "current rounding information" and in a non-interactive way. A label (for example, date or an accountant that can be agreed upon) and prior randomization is used to generate a new pseudo-randomness for shared values to add to the computations when they are followed by an update. This can sometimes extend to a full proactive update. With the use of the prior art with [FGMY], a complete proactivation is achieved without non-interactive faults (for example, all parties are honest and active in a round). This is the first time that such non-interactive maintenance is possible. It can be derived from [FGMY] by sharing affixes in the form of pairs, where each committee in a family adds an affix and the other affix is subtracted using a locally renewed new pseudo randomness. The locally renewed pseudo-randomness is derived from the old key applied to a global label that may be the global public state of this round. The new affix keys generate new common uses, followed by a non-interactive verification. The following is an example based on [F89], where the secret key d = S? + .... + If similar to [FGMY]. The new common uses now become s'¡ = s¡ +? Y =? ... / - i, / +? " sign (/ '- /) PFRs ?? and (fag). Before changing the s'¡, a signature for some label can be tested with the new common uses. For [FGMY], there are many settings s ?, ..., su (contained in a server family), so they add up to d, and more than one server can own s ,. For the robustness of the update, a commitment to s, -, is published as before. In addition, the distributor (a single distributor or one distributed) had published gs > . The commitment publication to PRFs¡j (tag) is provided by / using, for say ^ J, C¡, j = gPRFs \ tag). Entities / and / can now dispute if they disagree, and the value is open if necessary (one will be incorrect and will be removed). Each / also publishes gs? for the next round using their common usage, and the following verification is done by each v within a family, with dispute phase if necessary: gs, = Y'5"'~ J .. If there is no dispute, now is used, as in [FGMY2] that / can be converted to / ', and t can be converted to t' The efficiency that is obtained through the application of shared randomness in computations in proactive system updates, for example, is definitely applicable to the scheme in [R], as well as the "common sum use" scheme of [FGMY], which is very useful in relatively smaller scale systems Other public keys distributed (that are not RSA) can use this new primitive.

The description herein is exemplary and the notions described can be made in multiple forms. For example, shared randomness does not need to be incorporated into the exponent, for example PRF (fag) ga and PRF (tag) gb can be used in Diffie-Hellman contingent, as well as during the operational phase of distributed RSA signature (using instead of partial signature ",? m" • Algebraic operations other than addition can be used with shared randomization techniques, for example, if a distributed function is V = gs1"s7 mod P by computing V¡ = (Vμ) sl where Vo = g, shared randomness can be used as v. =. (tag)) s "tg ('~ J) The modalities described herein are intended to be illustrative and not limiting. possible within the scope and spirit of the invention.

Claims (8)

NOVELTY OF THE INVENTION CLAIMS

1. - A method for using cryptographic keys distributed among a plurality of distributed electronic devices, said distributed electronic devices have the ability to communicate with a central server, the method comprises the steps of: (a) computing shared values in a known and agreed context; (b) generate random values using the shared values; (c) generate a partial result for each device using the random values; and (d) compute an output based on the partial result.

2. The method for using distributed cryptographic keys according to claim 1, further characterized in that the shared values are random keys.

3. The method for using distributed cryptographic keys according to claim 1, further characterized in that the shared values are derived from a cryptographic protocol.

4. The method for using distributed cryptographic keys according to claim 1, further characterized in that the shared values are derived cryptographically.

5. - The method for using distributed cryptographic keys according to claim 1, further characterized in that it comprises the step to implement a re-representation of a function.

6. The method for using distributed cryptographic keys according to claim 1, further characterized in that the partial results may include incorrect values.

7. The method for using distributed cryptographic keys according to claim 1, further characterized in that steps (a) - (d) are performed iteratively.

8. The method for using distributed cryptographic keys according to claim 7, further characterized in that it comprises changing the shared values after the step to generate an output based on the partial result.