Matches in DBpedia 2014 for { <http://dbpedia.org/resource/Key_distribution> ?p ?o. }
Showing items 1 to 14 of
14
with 100 items per page.
- Key_distribution abstract "In symmetric key cryptography, both parties must possess a secret key which they must exchange prior to using any encryption. Distribution of secret keys has been problematic until recently, because it involved face-to-face meeting, use of a trusted courier, or sending the key through an existing encryption channel. The first two are often impractical and always unsafe, while the third depends on the security of a previous key exchange.In public key cryptography, the key distribution of public keys is done through public key servers. When a person creates a key-pair, he keeps one key private and the other, public-key, is uploaded to a server where it can be accessed by anyone to send the user a private, encrypted, message. Secure Sockets Layer (SSL) uses Diffie-Hellman key exchange if the client does not have a public-private key pair and a published certificate in the Public Key Infrastructure, and Public Key Cryptography if the user does have both the keys and the credential.In secret sharing, a secret (password, key, trade secret,...) is used as a seed to generate a number of distinct secrets, and the pieces are distributed so that some subset of the recipients can jointly authenticate themselves and use the secret information without learning what it is. Secret sharing is also called secret splitting, key splitting, and split knowledge. We want to share N secrets among M people so that any M < N of them (M of N) can regenerate the original information, but no smaller group up to M − 1 can do so. There are mathematical problems of this type, such as the number of points needed to identify a polynomial of a certain degree (used in Shamir's scheme), or the number of intersecting hyperplanes needed to specify a point (used in Blakley's scheme). We can hand out data specifying any number of points on the curve, or hyperplanes through the point, without altering the number needed to solve the problem and, in our application, access the protected resource.Key distribution is an important issue in wireless sensor network (WSN) design. There are many key distribution schemes in the literature that are designed to maintain an easy and at the same time secure communication among sensor nodes. The most accepted method of key distribution in WSNs is key predistribution, where secret keys are placed in sensor nodes before deployment. When the nodes are deployed over the target area, the secret keys are used to create the network. For more info see: key distribution in wireless sensor networks.== Asymmetric Key Distribution==Generic threshold key generation schemes ensure that all the participants are peers interms of their private-key shares. All of them can combine their shares in a similarmanner with no restriction or compulsion in participation. This also ensures that thereexists no monopoly or no centralized threat to the scheme. In a scheme with threshold t,any t of the total servers can combine to form a valid signature. The validity of thesignature is not governed particularly by the identity of the participating servers butsimply by their numbers. While for most public-key systems this will be ok, it will causea lot of trust-related issues to come up in systems where semi-trusting parties try to forma meaningful alliance. In such a scenario, it will be wiser to have a Special Server whokeeps a check on what is being signed by the group. This Special Server will have theextra ability to approve every certificate being collectively signed by all the servers. Noneof the servers will be able to create a valid signature on their own without the signatureshare of the Special Server.In order to provide such authority to the Special Server, it is to be ensured that even if allthe share servers were to cheat and try to sign a request illegitimately; they will not beable to do so by virtue of their shares. Their shares, under no circumstances will be ableto reproduce the Special Server’s share. In other words, the servers are no longer peers;the share distribution scheme is no longer symmetric.Asymmetric key distribution is an algorithm to ensure that the keys generated for such ascenario will not be symmetric and that authoritative power will remain in the hands ofone Special Server. It ensures that no certificate can be signed legitimately without the18signature of the Special Server. The strength of the algorithm comes from the efficientgeneration and distribution of the asymmetric key-shares. This maybe done with orwithout the use of a trusted Third Party or Honest Dealer. In the honest dealer case, theTrusted Dealer generates the appropriate shares and distributes them to the concernedplayers before the start of the certificate signing procedure. Every share server possessesits shares well before they start signing certificates in the system. Without an honestdealer, the share servers cooperatively generate their respective shares before a certificatesigning transaction.Here we introduce a model of the system to facilitate better understanding of thealgorithm. The details of the algorithm are discussed in the following sections..1 The Model:Share ShareServer 2 Server 3SpecialServer shareShareServer 1Share ShareServer 5 Server 4Fig.3.1: The Client Server Basic ModelConsider a Certificate Authority (CA) whose private-key is distributed among a fewservers to protect it. Fig 3.1 shows the typical distributed CA scenario where the servers19co-exist. One of the servers is a Special Server while the rest are similar and have peerfunctionalities. The Special Server and the share servers share a semi-trust relationshipand need to co-exist in order to sign certificate requests together as a group. The shareservers can communicate with each other as well as the Special Server. They may chooseto communicate with the Special Server either through individual channels or throughshare server who may act as a Server Authority.3.2 Trusted Dealer Overview:Share SpecialServer 1 ServerShare ShareServer 2 Server 5Share ShareServer 3 Server 4Fig 3.2: Distribution of generated key shares by the Trusted Dealer.3.3 Description of Players:Fig 3.2 shows all the players involved in the system. Each player has a unique role toplay and has limited functions. In a normal scenario, no player may imitate the functionsof another. Their unique functionalities are as described below. Trusted Dealer: The Trusted Dealer (TD) is an honest third party whose functionis to generate the secret components( modulus N, public exponent e, privateexponent d ) and divide the private-key into chunks and distribute it among theparticipants selectively. Once the Trusted Dealer chops up the private-key, it isnever assembled in a single location again. This dealer may not be compromised.Trusted DealerPrivate-key shares20Fig 3.2 shows the Trusted Dealer distributing private-key shares along with therest of the secret components to all the entities in the system. Server Authority: This is the intermediary authority above the share servers. Hisduty is to collect the individual shares of all the share servers, ensure that they arein the correct proportion as that required by the coalition and that none of themare compromised. The SA is capable of verification using zero knowledgetest[12]. It also performs Client Server Authentication using any known certificateauthentication technique. The requirement for an SA may be bypassed if one ofthe share servers is capable of the above-mentioned operations. In this scenario,we designate Share Server 1 as the SA authority to eliminate additional players. Share Servers: The share servers are a set of identical servers that maintainprivate key shares & the public key with themselves and are capable of executingcomplex arithmetic to come up with signature shares for certificate signing. Theirfunction is to collaborate with the other share servers and the Special Server tocollectively create valid signed certificates. Each one is capable ofcommunicating with the SA though they may or may not be able to communicatewith each other. They are not assumed to be secure or totally trusted and may becompromised by a strong enemy. Special Server: We define the Special Server as that share server which has theright of compulsory participation in any successful distributed key application.All its processing capabilities are identical to the share servers present in thesetup. The share generated by the Special Server is a requisite for the successfulgeneration of a valid signature. While the share servers may not be able to signthe certificate correctly without the Special Server’s participation, the SpecialServer also needs a minimum participation from the share servers in order for thetransaction to be valid.21Private KeyGenerated by trusted party Special Server Share Shared server Share k Share servers t-out-of k signature shares ƒ Signed Message. Fig 3.3: The Asymmetric Key Distribution algorithm3.4 Mathematical Analysis of the Asymmetric Key Distribution AlgorithmBefore the mathematical analysis, it is necessary to define all the key variables and themanner in which they are used.N : is a strong prime, which comprises of two strong, large prime factors p & q.Strong primes have certain properties that make the product N hard to factor byspecific factoring methods; such properties have included, for example, theexistence of a large prime factor of p-1 and a large prime factor of p+1. This isbecause certain factoring algorithms look for certain properties and strong primescan survive such factoring methods. Large primes survive most factoring methodsby virtue of their size. The amount of time taken to factorize, for example a 140digit number using the fastest factoring method today- the Number Field Sieve isapproximately 1.7 x 10 19 operations.22k : Total number of Share Servers present in the setup.t : Threshold, total number of Share Servers needed to apply shares for a transaction.The value of t should lie between (2k+1) and k. A threshold value of k wouldimply an absence of a threshold. Mathematically, the threshold selection for thissystem is made based on the following rule:(2k+1) ≤ t < k.t+1 : Number of valid signature shares required to sign a message successfully. Ofthese, t are provided by the share servers and one by the Special Server.d : private key exponent. This private key is never assembled during the course of theoperation. It is assumed that d k is chosen from a large enough set ( ideally, d k >max (p,q)) so that a cryptanalyst cannot find it by a direct search.e: public key exponent. This exponent is smaller compared to d k so that theverification process is faster. Typically, e=3.d s1 , d s2 ,d s3 , d s4 ,……d sk : private share server key shares.d ss : Special Server’s private-key share.M: A message, which the client wants, signed.Mx: An initial message sent by the trusted dealer if present in a scheme, containing thex th share servers private keys d sx .Ex, Dx : The encryption and decryption keys of the x th share server used in order to sendthe x th server its set of private keys initially.Assumption #1: The number of shares for generating a valid key is dependent upon thethreshold t. The value of t needs to be negotiated beforehand. In this setup, one of the23Share Servers (Server 1) decides the value of threshold t. It is also assumed that all otherfactors that need to be decided prior to setup are done either by Server1 or the SpecialServer.The Trusted Dealer computes the secret components (N, e, d ) and then starts dividing theprivate-key into smaller shares. The Trusted Dealer creates a set of t+1 private-key sharesfor every possible combination of t share servers. Each combination is marked by alookup that serves as an identifier for the share servers participating in that combination.The TD then sends each share server its private-key shares. Key share generation anddistribution by the Trusted Dealer is discussed in detail in the next section.We consider a generic scenario where the Special Server (SS) sends a message M, to besigned, to Server 1 (SA) who generates a random sequence of t numbers from 1 to k, todecide which of the k share servers participate in this Certificate Signing Request (CSR).Once the server combination is decided upon and the SS is made aware of thiscombination, the share servers are individually contacted by the Special Server(implementation preference * ). Each share server looks up its private-key sharecorresponding to this combination and computes its signature share as S 1 , S 2 , S 3 …S t ,where S i = M d i mod N.After computing their signature shares, the share servers send their signature shares eitherto the SS directly or to the SA. In the above-mentioned setup it would be to the SShimself as our objective here is to minimize communication overheads. In case of SAintervention, the SA passes on the uncombined shares to the Special Server only afterverifying that the servers are not compromised and that the shares are otherwiseauthentic. In the absence of an SA, the Special Server would perform the serververification. The SS on reception of t shares examines them & selects the appropriateprivate-key share out of its Ckt§ shares to successfully complete the signature request. Certain decisions, unrelated to the algorithm, were made at the time of implementation based on ease and minimumoverheads.§ Ckt=)! ( !!t k tk−is the number of combinations of k items taken t at a time.24Mathematically,The Client signature share is represented by:S c = M d c mod NAnd each of the t Share Server’s would create a share represented by:S i = M s i mod N where i ∈ {1,….k}.And finally the completely signed signature would be :S = S c x ∏=tii S1mod N.To check if the shares have been applied correctly, the client computes S e with the helpof the public exponent e and checks whether S e mod N = M. If that is the case, theprivate keys were applied correctly and the Signed Message S is a valid signature.3.5 Proof of correct Signature formation:If there are a total of t+1 shares required to make a valid signature coming from t ShareServers and one Special Server, the following is true:1 2 3 4 … t+1| | | | |S 1 = M d 1 mod N S 2 = M d 2 mod N S 3 = M d 3 mod N S 4 = M d 4 mod N …S t+1 = M d c mod NThen, S = ∏+=11tii S mod N i.e.,S = [S 1 x S 2 x S 3 x S 4… x S t+1 ] mod N25$ S = [(M d 1 mod N) x (M d 2 mod N) x (M d 3 mod N) x (M d 4 mod N) … x(M d t mod N) x (M dc mod N) ] mod N$ S = (M dc mod N) x t Π i=1 S i mod N$ S = S c x ∏+=11tii S mod NFurther, we see that$ S = M d 1 + d 2 + d 3 + d 4 +…+ d t + d c mod N$ S = M d mod N$ S is the complete signed signature equivalent to the complete key d being usedto sign the CSR.It can also be verified thus:S e mod N = M.If the signature was computed using the right shares, using the public exponent e onthe final signature results in getting the original message back again.3.6 Key Generation by the Trusted Dealer.The Trusted Dealer is responsible for the generation and distribution of the secretcomponents and the private-key shares to the concerned players in the systemappropriately.He generates the modulus N, the public exponent e, the complete private exponent d. Hethen chops up the private exponent d into the required number of private shares fordistribution. The secret components are generated in a technique similar to that used inthe RSA algorithm, which was described earlier.26In order to generate a modulus N, the Trusted Dealer starts by generating a very strong,large prime number p. The emphasis on strong and large has been highlighted earlier. Onsuccessful verification of its prime nature, it generates another prime number q of thesame order of magnitude as p. By order of magnitude of the secret components, we meanthe size of the numbers in bits. The two numbers p and q are known as the primederivatives of N. The TD computes N = p · q, which is of the order of magnitude of p +q. He selects the public key e such that e is relatively prime when compared to p and q.He computes the complete private-key d from e as per the RSA scheme. Once the private-key is computed, he sets himself to the task of splitting up the key into the requirednumber of secret key shares.3.7 Secret share generationSecret share generation is an important aspect of the key generation process. The size ofeach secret key share with respect to the complete key is of prime importance indetermining the security and confidence in the key share. Very small key shares can beexposed through brute force attacks. Blakley [27] and Shamir [1] were the first tointroduce t-out-of-k secret sharing schemes. In such types of schemes, at least t shares arerequired to successfully retrieve the secret. The knowledge of t-1 shares does not exposethe secret. While these schemes were mainly created as solutions to protecting secrets,other protocols invented by Ito, Saito, Nishizeki [28], Shoup [29], Benaloh and Leichter[30] were created to generate valid signatures and can be used for any arbitrary accessstructures. An access structure is a specification of all the subsets of participants who canrecover the secret and it is said to be monotone if any secret that contains a subset, canitself recover the secret. While Shoup’s scheme possesses reusability and verification,Shamir’s possesses none.Though any of the schemes mentioned above and more, may be used for the purpose ofsplitting the key into secret shares, we choose to implement a simplified scheme since itsuffices for the purpose of validating our scheme. We create a random modulus Z lessthan the private key d, called the splitting modulus and this modulus is used to create thesecret shares. For each shares of each set, we generate a new Z, namely, Z i . These Z i ’s are27stored in a moduli history array Z[] to avoid repetition and hence production of identicalshares in separate sets. Every Z i is checked against every previous Z i and (d - Z i ) in Z[]and recomputed in case of a match. Each share is computed as d mod Z i . The newremaining chunk of the key, new_d, obtained after each share is created is furtherrecursively split until the required number of shares is created. For every i, Z i is used aslong as the required number of shares has not been created and the value of thesubsequent key new_d is not less than Z i, in which case, Z i is recomputed and thecorresponding set is recreated. For every set, the Trusted Dealer verifies the key sharescomputed to ensure that they work correctly. They are subsequently stored.Part of the algorithm follows://Compute the number of sets requiredreduced_kCt =( kCt/(k-t+1) )//Begin generating the split-modulus Z for key share generation.OrigKey = key;for(SetCount=1; SetCount<=reduced_kCt; SetCount++){Z = GetZ; //Gets a random Z < private key d.//Calculation of the shares:int index =0;while(index <t){priv_share = key mod Z;if(priv_share > 0){d[index] = priv_share;key = key - (key mod Z);Z = GetZ;}index++;}//For last share:d[index]= key;for(int count=0; count<=t; count++){SumShares = SumShares + d[count];}//Checking validity of generated shares:if (SumShares == OrigKey){print(" Share generation correct ! ");}else {print("Incorrect share generation !! Need to redo !! ");28}//Put all shares in a 2D array of shares per set and writingto a file. (not shown)}//Function to get a non repeated value of ZGetZ{//getting a non zero random number Z lesser than key.Z = new BigInteger(key, 10, new Random); //BigIntegerway of generating random Z of the size of key.redoFlag=0;for(int i =0; i<=tempIndexCount; i++){if( ( Z == KeysMod[i]) || ( Z == key - keysMod[i] ) ){redoFlag=1;break;}}if (redoFlag ==0){//Z was correctly generated, store ZKeysMod[tempIndex] =Z;tempIndexCount= tempIndex;tempIndex++;}else if (redoFlag ==1){// Need to regenerate Z:Z = GetZ;}return Z; }Consider a simplified example, where the complete private key is 1000. We compute thefirst set to show how the shares would be computed for a threshold of 5.Table 3.1: Typical key share splitting for a single set for a private-key.key SetCount Z index priv_share d[index] key New Z1000 1 279 0 163 163 837 170837 1 170 1 157 157 680 535680 1 535 2 145 145 535 197535 1 197 3 141 141 394 251394 1 251 4 143 143 251 126251 1 126 5 xxxx xxxx xxxx xxxx29We begin with a key size of 1000 and as we progress through the algorithm, each newmodulus creates a share of the key. This process continues till the required number ofshare server shares is created. Once the required number of shares is created (as seen inrow 6), further splitting of the key is stopped and the remaining share is allotted to thespecial server. Thus, share servers S1 to S5 would be allotted d[0] to d[4] and d[5] toSpecial Server.If there are k Share Servers, any t out of which can combine to form a legitimatesignature along with the compulsory share from the Special Server, the Trusted Dealerwould need to split the private-key d into t +1 shares for each possible combination of thet-out-of-k Share Servers. In short, the Trusted Dealer would generate an array of keyshares for every possible combination of Share Servers in the system and a compulsoryshare for the Special Server for each of the combinations. This introduces morerandomness in the private-key share generation than the original threshold schemeproposed by Shamir[1] since there are more combinations of key shares with eachparticipant. It enables the servers to use different private shares for differentcombinations of Share Server coalitions. This way, the Trusted Dealer would need tocreate Cktsets of t+1 shares to accommodate all the possible combinations, which couldbe a computationally expensive process if k is comparatively larger than t. This overheadcan be reduced by intelligent reuse of key shares among certain servers withoutcompromising on the secrecy aspect of the private-key shares.For example, If the Trusted Dealer had to generate the private keys for a scenario wherethere was a 5-out-of-7 secret sharing among the Share Servers, then he would need togenerateCkt=C75= 21 different sets of 6 private shares which would be acomputationally heavy task. By intelligent reuse of key shares, the burden on the TrustedDealer is reduced by a factor up to (k-t+1).".
- Key_distribution wikiPageID "1725275".
- Key_distribution wikiPageRevisionID "606739927".
- Key_distribution auto "yes".
- Key_distribution date "December 2009".
- Key_distribution hasPhotoCollection Key_distribution.
- Key_distribution subject Category:Key_management.
- Key_distribution comment "In symmetric key cryptography, both parties must possess a secret key which they must exchange prior to using any encryption. Distribution of secret keys has been problematic until recently, because it involved face-to-face meeting, use of a trusted courier, or sending the key through an existing encryption channel.".
- Key_distribution label "Key distribution".
- Key_distribution sameAs m.05rclb.
- Key_distribution sameAs Q6398153.
- Key_distribution sameAs Q6398153.
- Key_distribution wasDerivedFrom Key_distribution?oldid=606739927.
- Key_distribution isPrimaryTopicOf Key_distribution.