Cryptografie aan het Werk

Cryptografie aan het Werk

Cryptografie aan het Werk Gerard Tel (Red.)

iv

Inhoudsopgave Inhoudsopgave Voorwoord v ix 1 Calling with Skype and Zfone (Rémon van de Kamp ) 1 1.1 The Public Switched Telephone Network.................. 1 1.2 Skype..................................... 2 1.3 Zfone...................................... 4 Summary and Conclusions............................. 7 2 Sleuteluitwisseling (Eelco Lempsink ) 9 2.1 Veiligheidseisen................................ 9 2.2 Protocollen.................................. 10 Samenvatting en conclusies............................. 15 3 NTRU (Mark Stobbe ) 17 3.1 NTRU..................................... 17 3.2 Aanvallen................................... 20 Samenvatting en conclusies............................. 21 4 Microsoft Crypto API (Pieter Hoogestijn ) 23 4.1 Cryptographic Service Providers....................... 23 4.2 Welke applicaties maken gebruik van de Crypto API........... 24 4.3 NSA invloeden op de CryptoAPI...................... 26 4.4 CryptoAPI in de aanval........................... 27 5 OpenPGP (Sander Schuckman ) 29 5.1 Werking.................................... 29 5.2 Berichtformaat................................ 31 5.3 Aanvallen................................... 33 Samenvatting en conclusies............................. 37 6 Side Channel Attacks (Kasper Brink ) 39 6.1 Achtergrond.................................. 39 6.2 Simple Branch Prediction Analysis..................... 43 6.3 Differential Power Analysis.......................... 47 Samenvatting en conclusies............................. 52 v

vi Inhoudsopgave 7 Hellman Voorbij (Max Waaijers ) 53 7.1 Time/Memory tradeoff aanvallen...................... 53 7.2 Time/Memory/Data tradeoff aanvallen................... 56 7.3 T/M/K aanval op UNIX wachtwoorden................... 58 7.4 Ondergrens.................................. 59 Samenvatting en conclusies............................. 60 8 UPnP TM (Paul Bouman ) 61 8.1 Doelstelling van UPnP TM.......................... 61 8.2 Ontwerp van UPnP TM............................ 62 8.3 Cryptografie in UPnP TM........................... 67 8.4 UPnP TM in de praktijk............................ 71 Samenvatting en conclusies............................. 73 9 Smashing SMASH (Roeland Luitwieler ) 75 9.1 Inleiding.................................... 75 9.2 SMASH.................................... 76 9.3 Het breken van SMASH........................... 82 Samenvatting en conclusies............................. 84 10 Privacy-Preserving Data Mining (Henno Vermeulen ) 85 10.1 Data Mining.................................. 86 10.2 Secure Multiparty Computation....................... 87 10.3 Mining Association Rules........................... 89 10.4 Secure Scalar Product Computation..................... 94 Summary and Conclusions............................. 99 11 Loterijen (Ruben van der Zwaan ) 101 11.1 Aanvallen................................... 103 11.2 Eigenschappen van loterijen......................... 104 11.3 Implementatie van een Elektronische Loterij................ 105 11.4 Technieken................................... 108 11.5 Samenvatting................................. 109 12 Digitale identificatie (R.A. van den Beukel ) 111 12.1 Definities................................... 112 12.2 Internetbankieren............................... 114 12.3 Elektronische Overheid............................ 118 12.4 Een gevaarlijke chaos............................. 120 Samenvatting en conclusies............................. 122 13 Hardeschijf versleuteling (Martin Warmer ) 123 13.1 Bestands versleuteling............................ 123 13.2 Een eerste oplossing.............................. 124 13.3 Getweakte versleuteling............................ 125 13.4 LRW-AES................................... 126 13.5 XTS-AES................................... 127

Cryptografie aan het Werk vii Samenvatting en conclusies............................. 129 14 Valkuilen bij kleine exponenten in RSA (Jefrey Lijffijt ) 131 14.1 Introductie in het kraken van RSA..................... 131 14.2 Oude bekenden................................ 132 14.3 Het kettingbreukalgoritme.......................... 133 14.4 Het roosteralgoritme............................. 134 14.5 Uit balans................................... 135 14.6 Staat van de kunst.............................. 135 Samenvatting en conclusies............................. 136 15 Een geheugen efficiënte achterdeur in RSA (Jos Roseboom ) 137 15.1 Elliptische krommen............................. 138 15.2 SETUP.................................... 142 Samenvatting en conclusies............................. 145 Bibliografie 147 Index 155

viii Inhoudsopgave

Voorwoord Deze bundel bevat literatuurstudies die besproken zijn op een klein symposium, genaamd Cryptografie aan het werk, gehouden op 25 januari 2007 aan de Universiteit Utrecht. Deelname aan het symposium en schrijven in deze bundel waren verplichtingen in het college Cryptografie (november 2006 tot januari 2007). Er werden 17 presentaties gehpuden (door 18 sprekers), verdeeld over de thema s Systemen, Aanvallen, Nieuwe toepassingen en Onderzoeksthema s: Ik hoop dat deze bundel de lezer een idee zal gevan van het symposium en van de inzet van de studenten. Gerard Tel, juli 2007. email: gerard@cs.uu.nl ix

Chapter 1 Calling with Skype and Zfone Written by Rémon van de Kamp This chapter is about security in Skype and Zfone. For completeness and comparison, a small section about calling via the Public Switched Telephone Network (PSTN ) is included. Througout this chapter, after the short overview of the PSTN, the encryption used in Skype and Zfone (The PSTN uses no encryption) will be described in terms of installation, call establishment and during a call. Skype will be described first and Zfone will be described after that. 1.1 The Public Switched Telephone Network The best known and most used way of calling is through the PSTN, the Public Switched Telephone Network. This is a circuit-switched network, meaning that when person A calls person B, a physical connection is made through the network between the two phones. All information goes through this connection, nothing is routed in other routes through the network. Because of this and because by default calls made this way are not in any way encrypted, calls can be eavesdropped only by persons who have physical access to either the call switching hardware within the phone company or the local loop 1. Eavesdropping in the local loop is very unlikely, because one would have to dig into the ground to reveal the phone line and this digging in public will of course draw lot attention. There exist phones that are able to encrypt calls, given that both ends of the conversation have the same type of phone, but this falls out of the scope of this chapter. 1 The local loop is the last section of phone line that goes from the local phone junction to the customer s house. 1

2 Calling with Skype and Zfone 1.2 Skype Skype is an immensely popular program for making calls. Originally it was created by Niklas Zennstrom and Janus Friis, who also developed KaZaA, but now it is in the hands of ebay, who bought it for $2.6 billion. From the beginning, despite several requests to disclose this, the creators have been vague about the encryption techniques used in Skype. So Skype relies on security by disclosure. Other systems have also relied on the disclosure of their cryptography, but have been revealed by reverse engineering 2. However the Skype executable uses anti-debug techniques, code obfuscation and an heavily encrypted executable, which is decrypted at run-time, directly after which the code for decryption is erased from memory, making it impossible to get a decrypted version of the whole executable[bd06]. As a result, there is no public information available about the real Skype encryption. Therefore, this section will be based on a document [Ber05] by Tom Berson of the Anagram Laboratories [KAMa]. He has worked for Skype for some time to analyze and criticize the cryptography used in their program. This makes it questionable how reliable a source he is (because he worked for Skype, Skype could have ordered him to bias his report). The rest of this section is information taken from his document, and can therefore unfortunately not be assumed to be the absolute truth about the workings of Skype. 1.2.1 Installation The cryptographic secret in Skype is the Skype Central Server s private signing key S S. Each client has the corresponding public verification key S V hard-coded in the executable. When a user uses Skype for the first time 3, he or she will be asked to provide a username (A) and a password (P A ). The application will then generate an RSA keypair V A,S A and send A, Hash 4 (P A ) and V A to the Skype Central Server, using AES with a session key that is created using random functions from the user s Operating System 5. The client can, and will check, that it is actually talking to the Skype Central Server 6. The Skype Central Server will check if the username is unique and otherwise acceptable under Skype naming rules 7. If this is the case, the server will store (A, Hash(Hash(P A )) in its user database. Next, it forms and signs an Identity Certificate for A, IC A, which contains, among other things 8, the Skype Central Server signature binding A and V A, {A, V A } S S and the key identifier of the S S. The Skype Central Server s Signing key used is determined by the fact wether the user has subscribed to extra options such as 2 For instance the encryption mechanism of mobile phones 3 Assuming he or she doesn t have a username/password combination already 4 It is currently unknown what hash-function Skype uses 5 It is currently unknown how this connection is established exactly 6 It is currently unknown how this is achieved, but probably via a challenge from the client which gets returned and signed by the server s signing key S S 7 For example that it has no invalid characters in it and is between 6 and 32 characters long, all of which is also checked client-side 8 It is currently unknown what other things

1.2 Skype 3 SkypeOut or SkypeIn. If the latter is the case, a S S with a modulus of 1536 bits will be used, otherwise a S S of 2048 bits will be used. After this process is done, IC A will be returned to A. 1.2.2 Establishing a call When a Skype user (U 1 ) calls another Skype user (U 2 ), a peer-to-peer connection will be made through the internet. How this connection is established falls out of the scope of this chapter. Once the connection is established, the peers challenge each other with 64 bits nonces 9. The peers modify these received nonces in a standard way 10, sign it with their own RSA private signing key S U1 and S U2 respectively, and send the result back to the sender. After this, they exchange their Identity Certificates IC P1 and IC P2. The receivers can verify that these Identity Certificates are signed by the server because they have the Skype Central Server s public verification key encoded in their executables. Because the verification key of the other user is included in his/her Identification Certificate, the receivers can now check the senders signatures used for the nonces. Finally, they send each other AES encrypted messages in which they agree on a 256 bits session key, to which both parties contribute 128 bits. The way in which this happens is undisclosed. It is stated by Tom Berson (see [Ber05]) that the two contributions are combined in a cryptographically-sound way, but he doesn t say exactly how. 1.2.3 During a call Once the call is established and the actual conversation data is being send back and forth, this data is encrypted using AES in Integer Counter Mode(ICM ). AES running in this mode is used as a key generator for package encryption, creating a keystream. Each buffer that is sent, is broken up into blocks and these blocks all get XORed with the cipher blocks coming from the AES keystream. AES in ICM is basically AES, but in this mode, not the data to be encrypted is encrypted by AES, but a special value, namely the counter, is encrypted. For Skype this counter is constructed in the following way: salt : salt : packet index : block#, where the semicolon stands for concatenation. The salts (random values) are salts provided by the users 11, both 32 bits 12. The packet index is 48 bits and its value is the index number of the buffer, which is incremented for each buffer. The block# is a 16 bit value containing the index number of the block currently being processed. 9 Nonces are random strings that have never been used before for this particular purpose 10 It is currently unknown in which way this is done 11 This is stated nowhere, but it s the only possible reason why there would be two salts 12 This is an assumption, since AES is running in 128 bit mode here, the whole counter has to be 128 bits, the packet index is 48 bits and the block# is 16 bits, this leaves 32 bits per salt, assuming that both salts have the same size

4 Calling with Skype and Zfone As said, this counter is encrypted for each block of each buffer and will then be XORed with the plaintext to be sent. Using AES this way has two advantages: 1. Because both sides of the conversation have the same counter running, it can be used to encrypt outgoing data (XORing the plaintext with the AES encrypted counter) and to decrypt data (XORing the incoming text with the same AES encryption) 2. The AES encryptions can be pre-computed, building a buffer of encryptions, so that when the CPU is temporarily unavailable (for example due to high load from other applications), XORing (which is a relative cheap operation) the plaintext can still be done with buffered AES encryptions. 1.3 Zfone Zfone is an extention for Voice Over IP (VOIP), created by Philip Zimmerman, the creator of Pretty Good Privacy (PGP). It is an extention in the way that you run together with a VOIP program and Zfone will take care of the security of the calls made with that particular VOIP program 13. All information about the Zfone protocol can be found in [Zim06]. 1.3.1 HMAC Zfone uses the Keyed-Hash Message Authentication Code (HMAC ) function, which is an extended hash function to send hashes. Readers familiar with the HMAC function can skip this subsection. The HMAC function is a function which takes two parameters, namely a key (K) and a message to be hashed (m) and mixes both in a combined hash function. In formula, the HMAC function works as follows[kamb]: ( ( ) ) HMAC K (M) = h (K opad) h (K ipad) m, where stands for concatenation, stands for the XOR operator and h is a standard hash function (for example SHA-1, MD5, etc). Opad (outer padding) and ipad (inner padding) have default values, namely opad = 0x5c5c5c...5c5c and ipad = 0x363636...3636. The HMAC function is basically a hash function that hashes the message together with a key. This way, two hashes of the same text can be made, resulting in different outcomes when a different key is used. Analogue to this, two different messages hashed with the same key also produce different outputs. 13 Examples include X-Lite, Gizmo en SJPhone. It doesn t work with Skype, because Skype doesn t use the VOIP protocols SIP and SRTP, but its own protocol.

1.3 Zfone 5 1.3.2 Installation On installation of Zfone, the program creates an unique ZID (Zfone ID), with a length of 96 bits. This ZID is used for caching of retained secrets. Retained secrets are HMAC s of session keys used in previous calls. These are used for authentication. Zfone doesn t have its own username-system, because it relies on the Session Initiation Protocol (SIP) used in VOIP to do this. 1.3.3 Establishing a call Note: because the Zfone call establishment protocol is a very extensive protocol, this is an overview of how calls are established. All information about the Zfone protocol can be found in Zimmermann s Internet Draft about Zfone [Zim06]. Call establishing in Zfone is started with the normal procedure for VOIP to do this, namely via SIP. SIP for VOIP can be compared with DNS for HTTP. Once the connection is established, the Real-Time Transport Protocol (RTP) starts, which is the basic carrier for the voice data. At this point, Zfone kicks in. Zfone initialization works in four phases: 1. Discovery This is performed in the headers of the RTP stream. This can be done, because RTP, by default, ignores unknown headers. So if one peer has Zfone and the other doesn t, the other peer won t get confused by the messages. During this discovery phase, both peers exchange their ZID s, ZRTP version and which algorithms are supported 14. The received ZID s are used to retrieve previous shared secrets. 2. Hash commitment In this phase, the initiator chooses, from the intersection of the algorithm support exchange in the discovery phase, which algorithms will be used. It also chooses a secret value for Diffie-Hellmann exchange, sv i and calculates the corresponding Diffie-Hellman public value, pv i. Last step in this phase is that the initiator creates a hash hv i of his pv i concatenated with the chosen algorithm information and sends this to the responder. 3. Diffie-Hellmann exchange This phase is started by the responder calculating his Diffie-Hellmann secret value sv r and corresponding public value pv r and creates HMAC s 15 of all possible shared secrets, for a example for Retained Secret 1 rs 1 : HMAC(rs 1, Responder ) Apart from rs 1 and rs 2 there are 3 more secrets: 1. Sigs This will be the secret of Secure SIP, in case this protocol is used 2. SRTPS This will be the secret of Secure RTP, in case this protocol is used 3. other secret - a secret the users have agreed on offline, for example a password 14 Specifically algorithms for hash, cipher, auth tag length, key agreement type and SAS 15 See the subsection on HMAC s for explanation

6 Calling with Skype and Zfone The responder now sends his pv r together with the set of HMAC s to the initiator. The initiator does the same, but then with his shared secrets. When the responder receives the message from the initiator it can check that the hash of his public value pv i concatenated with all possible version information corresponds with the hash hv i it got earlier. If this is not the case, a man in the middle is present trying to do a bid-down-attack 16 and the call will be terminated. If the latter is not the case, both ends will calculate the Diffie-Hellmann Shared Secret and calculate the session key as follows: s 0 = hash(dhss s 1 s 2 s 3 s 4 s 5 ) 4. Confirmation and switch to SRTP Both users can now calculate the SRTP key and salt, which is done as follows (for the initiator): SRT P Key i = HMAC(s 0, Initiator SRT P master key ) SRT P sals i = HMAC(s 0, Initiator SRT P master salt ) The responder does the same, but uses the strings Responder SRTP master key and Responder SRTP master salt. Now RTP is switched to SRTP (Secure RTP) with the calculated keys and salts. If SRTP was already being used it will be reinitialized with the new keys and salts. Both users will now calculate a retained secret as follows: rs 1 = HMAC(s 0, retained secret ) If there already was an rs 1, this will become rs 2 and a if an rs 2 was also present, it will be deleted. The retained secret will be used for future calls. Finally, both users see a 4 character Short Authentication String ( SAS) in their GUI, which they must confirm is identical on both ends. One user must read the first two characters aloud and the other user must read the last two characters aloud. The value of the SAS is the last 32 bits of: SAS = hash(pv i pv r Short Authentication String ) Because both users know their own public value and received the public value of the other party, the hashes should be the same on both ends, if not, a man in the middle has been fooling with their public values. 1.3.4 During a call During the call, data is encrypted by XORing the plaintext to output from AES running in ICM, just as with Skype. There is however a small difference, namely that Zfone doesn t use concatenation of salts, packet indicices and block# s, but an ordinary counter (starting with 1, then 2, 3, 4, etc). The AES used here uses 128 bits keys (the counters) and 112 bits salts (which is actually used as encryption key for AES). 16 A bid-down-attack is an attack where the MitM will modify the message in the discovery phase regarding the supported algorithms by changing the supported algorithms to very weak algorithms, in order to make hacking easier for himself.

Summary and Conclusions 7 Summary and Conclusions The PSTN has been a reliable systems for decennia now, but with the upcoming of internet with VOIP and Skype, these are becoming very good, cheaper, alternatives. The security used in VOIP with Zfone is very good and will guarantee to a very high degree that eavesdropping is impossible. If security in really works as described above, but because, as stated before, nothing is known for sure about Skype Security, Skype is a secure protocol, but no certain claimed can really be made about this.

8 Calling with Skype and Zfone

Hoofdstuk 2 Sleuteluitwisseling Door Eelco Lempsink Op internet komt het regelmatig voor: twee partijen die geen geheime informatie delen, maar via een onbeveiligd kanaal graag een sleutel willen afspreken om informatie symmetrisch te versleutelen. Daarnaast willen ze ook elkaars identiteit controleren. Dit hoofdstuk behandelt een aantal protocollen om dat mogelijk te maken en zal daarbij vooral ingaan op de veiligheid van die protocollen. Met de demonstratie van enkele aanvallen wordt getoond hoe kwetsbaar sommige protocollen kunnen zijn. 2.1 Veiligheidseisen Bij het claimen van de veiligheid van een protocol is het belangrijk om ook te definiëren wat die veiligheid inhoudt. Toch is dit van veel bestaande protocollen niet (formeel) gedaan. Er zijn verschillende soorten veiligheid die belangrijk zijn in de context van een protocol voor sleuteluitwisseling. Hierbij wordt voor het gemak een aanval waarbij de sleutel geraden wordt achterwege gelaten, dit is namelijk een eigenschap van de sleutel, niet van het protocol. Veiligheidseis 2.1 Een protocol waarbij het mogelijk is om je uit te geven voor iemand anders, is niet veilig voor sleuteluitwisseling. Deze eis mag voor zichzelf spreken, maar er zijn ook een aantal veelgebruikte eisen die uitgaan van een ingewikkelder situatie: de realiteit. Informatie kan lekken of gestolen worden. De mate waarin een protocol nog veilig is ondanks dat gevoelige informatie is uitgelekt wordt gedefinieerd door verschillende eisen. Veiligheidseis 2.2 Het uitlekken van sleutelinformatie van een sessie mag alleen gevolgen hebben voor de betreffende sessie. Andere sessies tussen dezelfde gebruikers of andere gebruikers mogen daardoor niet kwetsbaar worden. 9

10 Sleuteluitwisseling Veiligheidseis 2.3 Een protocol voldoet aan de Authenticated Key Exchange (AKE) veiligheidseis als er geen aanval mogelijk is die een voordeel geeft bij een AKE experiment. Een AKE experiment vindt plaats in een situatie waarin de aanvaller alle communicatie controleert en sommige partijen kan kraken. De aanvaller kan bepalen welke twee eerlijke partijen een sleuteluitwisseling gaan doen. Om te slagen voor het experiment krijgt de aanvaller in een eerlijke test-sessie een challenge voorgelegd waarvan hij moet bepalen of het een willekeurig getal is of de sleutel van de test-sessie. Bij de aanvallen op de protocollen worden alleen actieve aanvallen [Tel06] behandeld, zoals de definities van de veiligheidseisen al suggereren. De onderstaande aanvaller gaat zelfs nog een stapje verder, door ook actief de communicatie te verstoren. Definitie 2.4 Een aanvaller kan een sessie verstoren door volledige controle over een eerlijke partij te nemen. Daarnaast onderscheiden we twee soorten aanvallers: Definitie 2.5 Een zwakke aanvaller kan sessie-sleutels stelen van eerlijke deelnemers aan een sleuteluitwisseling. Definitie 2.6 Een sterke aanvaller kan zowel sessie-sleutels als tijdelijke geheime sleutels stelen van eerlijke deelnemers aan een sleuteluitwisseling. Als een aanvaller een sessie verstoort door een eerlijke partij over te nemen of gegevens te stelen dan is deze sessie niet meer eerlijk. 2.2 Protocollen Van de verschillende protocollen zal ook behandeld worden hoe ze kunnen worden aangevallen. In de uitwerking van de protocollen worden de twee eerlijke partijen weergegeven als A en B. In aanvallen is er een derde partij M die de aanval uitvoert. Verder is er een generator g (van een groep G, orde een priemgetal) die gebruikt wordt om het publieke evenbeeld van geheime sleutels te maken. 2.2.1 Signed Diffie Hellman De eenvoudigste manier om sleutels uit te wisselen is het Diffie Hellman sleutelprotocol, zoals onder andere beschreven in [Tel06] en [JFS00]. Figuur 2.1 laat zien hoe het protocol in z n werk gaat. Beide partijen genereren een (tijdelijke) geheime sleutel x respectievelijk y. Daarmee wordt een publieke sleutel gegenereerd die naar de andere partij wordt gestuurd. Door de eigen geheime sleutel met de publieke sleutel van de ander te combineren kunnen beide partijen zonder verdere communicatie dezelfde sleutel uitrekenen. De echte sleutel(s) worden dus in werkelijkheid niet uitgewisseld, alleen de informatie om die te kunnen berekenen.

2.2 Protocollen 11 A x K = g xy g x g y B y K = g xy Protocol 2.1: Diffie Hellman De reden dat er tijdelijke sleutels worden gebruikt heeft te maken met de veiligheid van toekomstige communicatie. Hoe langer een sleutel bestaat, hoe groter de kans dat hij door onvoorzichtigheid of diefstal in de verkeerde handen is gevallen. Het beste is dus elke keer nieuwe tijdelijke sleutels te creeëren, maar dat zou door de tijd die het berekenen kost onaantrekkelijk kunnen zijn in de praktijk. Het protocol is zeer kwetsbaar voor een man-in-the-middle aanval door M en voldoet daardoor niet aan veiligheidseis 2.1. De enige vaardigheden die M nodig heeft is het kunnen vervangen van de verstuurde informatie. Voor het vervangen gebruikt M een x en y (kunnen hetzelfde zijn). Door zowel A als B een bewerkte publieke sleutel op te sturen zullen ze allebei een sleutel genereren die M ook weet, op basis van zijn eigen geheime informatie en de opgevangen publieke informatie. M kan nu alle berichten die A en B aan elkaar sturen lezen en natuurlijk ook zelf zich uitgeven voor een van hen en de andere partij een bericht sturen. De aanval is schematisch weergegeven in figuur 2.2. Daarnaast voldoet het Diffie Hellman protocol niet aan de wens om ook de identiteit van de andere partij de kunnen controleren, maar dat is gelukkig snel verholpen door ook een digitale handtekening mee te sturen. Dit wordt het Signed Diffie Hellman (SDH) protocol genoemd, te zien in figuur 2.3. SIG A betekent de handtekening van partij A. De data die ondertekend wordt is de publieke sleutel van de versturende partij, gecombineerd met de identiteit van de ander. Voor het maken en controleren van de handtekeningen is ook een publieke en geheime sleutel nodig. Omdat dit niet direct relevant is voor de sleuteluitwisseling is de exacte werking daarvan niet weergegeven in het figuur. Doordat in dit geval ook een signatuur van de verstuurde publieke sleutel wordt meegestuurd zal de eerdere man-in-the-middle niet op dezelfde manier een onopgemerkte A M : x, y B x g x gx g y gy y K A = g xy K B = g x y Figuur 2.2: Man-In-The-Middle aanval op Diffie Hellman

12 Sleuteluitwisseling A x g x, SIG A (g x, B) g y, SIG B (g y, A) K = g xy B y K = g xy Protocol 2.3: Signed Diffie Hellman aanval kunnen uitvoeren. Hij zal dus naar sterkere middelen moeten grijpen. Voor een succesvolle aanval heeft M een tijdelijke geheime sleutel nodig. Met die kennis is namelijk kan de kwaadwillende partij namelijk al zich uitgeven voor iemand anders, door dezelfde (afgeluisterde) publieke sleutel en handtekening te gebruiken. Dat betekent dus dat M een zwakke aanvaller moet zijn, zoals gedefinieerd in definitie 2.5. Het mag duidelijk zijn dat dit protocol niet veilig genoeg is om in de praktijk te gebruiken. Door de tijdelijke sleutels is voldoet het weliswaar aan de veiligheidseis 2.2, mits deze slechts één keer gebruikt worden, maar het is voor M niet moeilijk een succesvolle aanval uit te voeren. 2.2.2 KEA Het Key Exchange Algorithm (KEA) protocol is ontwikkeld door de NSA. Na enkele jaren als geheim protocol gebruikt te zijn, werd in 1998 het algoritme vrijgegeven. Zonder bewijs dat het veilig was, maar aangezien er ook geen aanvallen bekend waren, werd dat niet meteen als een probleem gezien. Het protocol werkt in tegenstelling tot SDH met een permanente geheime en (geregistreerde) publieke sleutel, weergegeven als a, g a en b, g b. Voor de rest verschilt het protocol slechts in de manier waarop de sleutel gegenereerd wordt. Zoals te zien is in figuur 2.4 wordt de sleutel opgebouwd uit een combinatie van de publieke sleutel en de tijdelijke geheime sleutel. De functie F in het figuur is gedefineerd als cryptografische hash functie. In de definitie van het oorspronkelijke protocol was dit een functie van de SKIPJACK blok-versleuteling [NIS98]. De identiteit van de wederpartij wordt vastgesteld aan de hand van de publieke A : a, g a x g x g y B : b, g b y K = F (g ay g bx ) K = F (g ay g bx ) Protocol 2.4: Key Exchange Algorithm

2.2 Protocollen 13 Kader 2.5: PCMCIA Veiligheidskaarten Een hardware-implementatie van (onder andere) het KEA protocol is te vinden in de zogenaamde Fortezza PCMCIA kaarten, gemaakt door het bedrijf Spyrus [Spy]. De kaarten worden op grote schaal ingezet door het Amerikaanse Ministerie van Defensie voor het veilig versturen van e-mail (zie ook Kader 2.8. Sinds 1993 zijn er zo n 300.000 kaarten verkocht. Doordat de implementatie van het protocol geheel in hardware is gemaakt, is het naast snel ook een stuk lastiger (volgens de fabrikant onmogelijk) om gegevens zoals tijdelijke geheime informatie te pakken te krijgen. sleutel, die ook in de berekening van de sleutel wordt meegenomen. Hier ligt echter ook de mogelijkheid voor een boosdoener. Lauter en Mityagin hebben in 2006 laten zien dat KEA kwetsbaar is voor een zogenaamde Unknown Key Share (UKS) aanval [LM06]. De opbouw van een dergelijke aanval is weergegeven in figuur 2.6. Definitie 2.7 Met een protocol dat gevoelig is voor een Unknown Key Share aanval berekenen twee partijen dezelfde sessie-sleutel maar hebben ze een incorrect beeld van de partij waarmee ze die sleutel berekenen. Dit betekent dat niet aan veiligheidseis 2.1 en 2.2 wordt voldaan. De kwaadwillende partij M heeft dezelfde publieke sleutel geregistreerd als partij A. Voor deze aanval is het van belang dat M volledige controle heeft over de communicatie. Bij het heen en weer sturen van de publieke sleutels tussen A en B kan M niet alleen meeluisteren, maar ook de informatie veranderen. Daarnaast kan een sessie worden gebruikt als test-sessie. In zo n sessie stuurt de ene partij ofwel een random string of de sessie-sleutel naar de andere partij die dan moet verklaren wat hij opgestuurd heeft gekregen, zoals ook beschreven in veiligheidseis 2.3. Een onwetende aanvaller heeft dus slechts kans 1 om het goed te hebben. Voor een succesvolle aanval moet de aanvaller 2 dus met een grotere kans dan 1 slagen in de test-sessie. 2 A : a, g a M : g a B : b, g b x g x g y y g x K = F (g ay g bx ) K = F (g ay g bx ) Ki = F (g ay g bx ) Figuur 2.6: Unknown Key Share aanval op KEA