Академический Документы
Профессиональный Документы
Культура Документы
Preparedby Name: MuhammadNoorshazmilBinMohdZahri MatricNo.: 107608 Preparedfor Pensyarah: Dr. Aman Jantan
Diffie-Hellman Key Exchange Method on Cryptographic Keys MuhammadNoorshazmilBinMohdZahri,107608 UNIVERSITISAINSMALAYSIA ComputerScience mnoorshazmil.ucom10@student.usm.my
Abstract What is DiffieHellman (DH), and why should you care? The ability to distribute cryptographic keys securely has been a challenge for centuries. The DiffieHellman key exchange protocol was the first practical solution to the key exchange dilemma. The DiffieHellman protocol allows two parties to exchange a secret key over unsecured communication channels without meeting in advance. The secret key can then be used in a symmetricencryptionapplication,andthetwo parties can communicate securely. DH is a mathematical algorithm that allows two computers to generate an identical shared secret on both systems, even though those systems may never have communicated with eachotherbefore.Thatsharedsecretcanthen be used to securely exchange a cryptographic encryption key. That key then encrypts traffic betweenthetwosystems.
systemsbecauseasymmetrickeymanagementis much easier. In a symmetric key system, both sidesofthecommunicationmusthaveidentical keys.Securelyexchangingthosekeyshasalways been an enormous issue. At one time, the National Security Agency maintained an entire fleet of trucks and planes manned by armed couriers to shuttle around 15 tons of paper based symmetric key used by the U.S. government every year. Businesses simply do not want to mess with that sort of burden.
1.0 INTRODUCTION
TheDHalgorithm,introducedbyWhitfieldDiffie
Asymmetric key systems alleviate that issue because they use two keys: one called the privatekeythattheuserkeepssecret,andone
and Martin Hellman in 1976, was the first called the public key that can be shared with system to utilize publickey or asymmetric the world and, therefore, easily distributed. cryptographickeys.Thesesystemsovercomethe Unfortunately, the advantages of asymmetric difficulties of privatekey or symmetric key
key systems are overshadowed by speedthey are extremely slow for any sort of bulk encryption. Today, it is typical practice to use a symmetric system to encrypt the data and an asymmetric system to encrypt the symmetric keys for distribution. That is precisely what
Today our concern is not who discovered the process,buthowtosharesymmetrickeysinan insecure network. Most networking vendors look at the Public Key Cryptography Standard (PKCS)#3standardtoimplementDH.
Simply put, DH is typically not used to encrypt DiffieHellman is capable of doingand does user data, but is, in most cases, used by VPN dowhen used for key exchange as described implementations to share keying information here. securely,suchasDES,3DES,AES,SHA,MD5and However, there is evidence to prove that these Whitfield Diffie, Martin Hellman, and Ralph Merkle actually didn't discover the othersymmetrickeys,acrossaninsecurepublic network, like the Internet. DH uses public key cryptography(asymmetrickeying)toaccomplish this. Therefore, it is commonly referred to as a publickeyexchangemethod.
public/private key cryptography process; rather it was one of two government agencies of the British or the U.S. (National Security Agency)
Many VPN implementations, such as IPsec, use government10yearsbeforeDiffie,Hellman,and DH to share symmetric encryption keys in a Merkle developed a similar process secure fashion. For instance, IPsec's RFCs 2401, independently.Theseprocesses,however,were 2408,and2412relyontheuseofDHforsharing kept secret from the public; and whereas this of keying information for HMAC functions, such information was classified and never published, asMD5andSHA,andencryptionalgorithms,like these three people created the same solution DES,3DES,andAES. forpublicuse.
throughtheDHalgorithm.
4. The mathematical beauty of the DH algorithm is that even though different inputs are fed into the algorithm, thesameoutputresultsonbothsides:Diffie,
1. Each of the two peers shares information that will help them create their own public/private key combinations; this is necessary because DH supports varying key
Hellman,andMerklefiguredoutthatifyou haveonepairofvaluesthathavearelation, and another pair of values that have a relation, when you exchange one value for
sizes, called keygroups. I'll discuss DH key groups after these numbered steps. Once
another in the different pair, there is still a relationship between the values. I have a
thekeysizeisknown,thetwopeerscreate degreeinmathematics,butcomingupwith their personal public/private key pair combination. Actually, each creates its private key first, and uses a derivative process to derive the public key from the privatekey. 5. Because PeerA created the symmetric encryption key for the financial data, PeerA 2. Each peer shares its public key with the encrypts thedatawiththeoutputkeyfrom remotepeer. the DH algorithm, Secret_key_X, and sends 3. Eachpeertakesitspersonalprivatekeyand theremotepeer's public key and runs them the encrypted symmetric encryption key to PeerBacrossthenetwork. thisproofiswaybeyondmyabilitiesI'mjust gladthesethreeguysmadeiteasierforme tosetupsecurenetworks!
6. When PeerB receives the encrypted key, PeerB uses the same derived DH key,
Secret_key_X,todecryptthesymmetrickey, groups. In this table, the first column indicates resulting in "If you can guess this key, you the name of the key group, denoted by a win a lollipop!"; therefore, when PeerA number.Followingthisisthelengthofthekeys, sends financial data to PeerB, PeerB will be and, in the last column, the type of algorithm able to decrypt it successfully with the used to create the shared secret key. DH key symmetricencryptionkey. groups are commonly referred to with their Figure24.TheDiffieHellmanProcess number,asinDHgroup1.
Table21.DHKeyGroups Key Length Equation Group 1 2 3 DH uses key groups to define how the shared secretkeyisactuallygenerated.Thekeygroups define the key length for the public and private keys and the DH algorithm to use in generating thesharedsecretkey. 15 7 14 4 5 768 bits 1,024 bits 155 bits 185 bits 1,536 bits 163 bits 2,048 bits 3,072 Straightalgorithm Straightalgorithm Ellipticalcurvealgorithm Ellipticalcurvealgorithm Straight algorithm (most secure key group supported byCisco) Ellipticalcurvealgorithm Straightalgorithm Straight algorithm (most
intensive, the key sizes are kept small so that Table21.DHKeyGroups Key Length Equation Group bits Straight algorithms use a normal computation process, like an equation, to produce a secure key. The longer the bit length is for a straight algorithm,thestrongertheresultingsecretkey. But straight algorithms and keys with long bit lengths are very computationalintensive. For example, a Cisco 7200 router with a VAM card would have no problemprocessing a straight algorithm using DH group 15; however, a personal digital assistant (PDA) device doesn't havethatcapacity. secure key group, but Cisco doesn'tsupportit) limitedprocessingdevicescanstillusethem.
To accommodate devices that have limited processingpower,ellipticalcurvealgorithmsare used; they can use a smaller key size, but can create a more secure result than a
a VPN implementation should support is managementofkeys:theabilitytorefreshthem periodically in a dynamic, secure, inband fashion, reducing the amount of physical managementtoaverysmallamountoftime.For example, DH doesn't specify how to deal with
key management functions; however, VPN implementations, such as IPsec, have other componentsthathandlethisprocess. Onestrengthofasymmetrickeyingalgorithmsis that the private key, used to decrypt information, is never sent across the network. And with DH, the derived secret key also never traversesthenetwork.Thusanattacker,evenif heiseavesdroppingonthepublickeyexchange process and sees the exchanged public key or keys,wouldn'tbeabletousethistodecryptany transmittedinformation.Inasimpleasymmetric algorithm implementation, the eavesdropping attackerwouldhavetoknowtheprivatekeyto decrypt information; and in the case of DH, the attackerwouldhavetoknowofoneofthetwo private keys to decrypt information. However, DH does have one main weakness: it is susceptible to a maninthemiddle attack. I'll usethePeerAtoPeerBexample.PeerAneedsto encryptfinancialdatatoPeerB.Inthisexample, assumeDHisbeingusedforsharingkeys.PeerA initiates a connection to PeerB; assume that
instead of the real PeerB responding back, a maninthemiddle attack occurs and the attacker's device responds back. DH, however, assumes that the two devices trust each other. In the PeerAtoPeerB example, especially if they'reseparatedbyapublicnetwork,theyhave noideaifthey'reinteractingwitheachother,or with some device pretending to be one of the two parties.In other words, key exchange protocolssuchasDHdealstrictlywithonething: key exchanges. They don't deal with other
authentication
mechanisms.
Some
componentisrequiredtoverifytheidentitiesof the two devices to ensure that PeerA doesn't mistakenly send sensitive financial data to a maninthemiddledevice(attacker).
periodoftime,exposingthemtoincreased vulnerability. Theexchangerequiresnopreexisting infrastructureotherthananagreementonthe globalparameters. However,thereareanumberofweaknessesto DiffieHellmanalgorithm: Itdoesnotprovideanyinformationaboutthe identitiesofbothparties.Soitisvulnerableto impersonationattack. Itiscomputationallyintensive.Asaresult,itis vulnerabletoacloggingattack,inwhichan opponentrequestsahighnumberofkeys.The victimspendsconsiderablecomputingresources doinguselessmodularexponentiationrather thanrealwork. Itcannotpreventreplayattack. Itissubjecttoamaninthemiddleattack,in whichathirdpartyCimpersonateswhile communicatingwithAandimpersonatesAwhile communicatingwithB.BothAandBendup
negotiatingakeywithC,whichcanthenlisten toandpassontraffic. Themaninthemiddleattackproceedsas follows: step1:AC(B):XAmodq step2:C(A)B:XCmodq step3:BC(A):XBmodq step4:C(B)A:XCmodq UserAgeneratesaonetimeprivatekey XA,calculatesYA,andsendshispublickeyYAina messageaddressedtouserB.TheenemyC interceptsAsmessage.CsavesAspublickey (YA)andgeneratesaonetimeprivatekeyXC, calculatesYC,andsendshispublickeyYCina messagetouserB.ThismessagetoBhasAs UserIDbutCspublickeyYC.Thismessageis sendinsuchawaythatitappearsasthoughit wassendfromAshostsystem.BreceiveCs messageandstoresCspublickeywithAsUser ID.
achieveauthenticationisarelativelysimple, economicalandpracticalprogramswithout additionalpublickeyinfrastructureasasupport. BecauseofincludingAuthenticationmechanism, theimprovedDiffieHellmankeyexchange Similarly,CsendsamessagetoAwithCspublic key(YC),purportingtocomefromB.Acalculates asecretkeyK1((YC)XAmodq)basedonXAand YC.CcalculatesK1((YA)XCmodq)usingXCand YA.SoK1issharedbyAandC.Bcalculatesa secretkeyK2((YC)XBmodq)basedonXBandYC. Ccalculates((YB)XCmodq)usingXCandYB.SoK2 issharedbyBandC.FromnowonuserAthinks K1issharedwithB,userBthinksK2isshared withA,butnokeyissharedbyAandBactually. SoCisabletorelaymessagesfromAtoBand fromBtoA. protocolcanresistreplayattack,impersonation attackandmaninthemiddleattack.The simulationresultsintheLANprovethat authenticationusinghashfunctionhastheless computingquantityandthefastercomputing speedthantheotherpublickeyandsymmetric keyencryptionalgorithm.Ithasahighpractical valueinbuildingasecurecommunication channelofsymmetrickey.
7.0 REFERENCES
1. DiffieHellman Key Exchange,
6.0 CONCLUSION
ByanalyzingthesecurityoftheDiffieHellman protocol,thispaperpresentsanimprovedkey exchangeprotocolbasedonrandomnumber sequence.Thisprotocolusingahashfunctionto
3.
DiffieHellmaan
key
exchange,
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm an_key_exchange 5. DiffieHellman key exchange by Matt Ryall, http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm an_key_exchange 6. DiffieHellman Key Exchange A Non Mathematicians Explanation,
http://www.rsa.com/rsalabs/node.asp?id=2248