Cryptografie aan het Werk

Cryptografie aan het Werk

Cryptografie aan het Werk Gerard Tel (Red.)

iv

Inhoudsopgave

Inhoudsopgave

v

Voorwoord

ix

1 Calling with Skype and Zfone (Rémon van de 1.1 The Public Switched Telephone Network . . 1.2 Skype . . . . . . . . . . . . . . . . . . . . . 1.3 Zfone . . . . . . . . . . . . . . . . . . . . . . Summary and Conclusions . . . . . . . . . . . . .

Kamp . . . . . . . . . . . . . . . .

) . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 2 4 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 ) 4.1 Cryptographic Service Providers . . . . . . . . . . . . 4.2 Welke applicaties maken gebruik van de Crypto API 4.3 NSA invloeden op de CryptoAPI . . . . . . . . . . . 4.4 CryptoAPI in de aanval . . . . . . . . . . . . . . . . 5 OpenPGP (Sander Schuckman 5.1 Werking . . . . . . . . . . 5.2 Berichtformaat . . . . . . 5.3 Aanvallen . . . . . . . . . Samenvatting en conclusies . . .

) . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

23 23 24 26 27

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

29 29 31 33 37

6 Side Channel Attacks (Kasper Brink ) 6.1 Achtergrond . . . . . . . . . . . . . . 6.2 Simple Branch Prediction Analysis . 6.3 Differential Power Analysis . . . . . . Samenvatting en conclusies . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

39 39 43 47 52

. . . .

. . . .

. . . .

. . . .

v

vi

Inhoudsopgave

7 Hellman Voorbij (Max Waaijers ) 7.1 Time/Memory tradeoff aanvallen . . . 7.2 Time/Memory/Data tradeoff aanvallen 7.3 T/M/K aanval op UNIX wachtwoorden 7.4 Ondergrens . . . . . . . . . . . . . . . Samenvatting en conclusies . . . . . . . . . . 8 UPnPTM (Paul Bouman ) 8.1 Doelstelling van UPnPTM 8.2 Ontwerp van UPnPTM . . 8.3 Cryptografie in UPnPTM . 8.4 UPnPTM in de praktijk . . Samenvatting en conclusies . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9 Smashing SMASH (Roeland Luitwieler ) 9.1 Inleiding . . . . . . . . . . . . . . . . . 9.2 SMASH . . . . . . . . . . . . . . . . . 9.3 Het breken van SMASH . . . . . . . . Samenvatting en conclusies . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

10 Privacy-Preserving Data Mining (Henno Vermeulen ) 10.1 Data Mining . . . . . . . . . . . . . . . . . . . . . . . 10.2 Secure Multiparty Computation . . . . . . . . . . . . 10.3 Mining Association Rules . . . . . . . . . . . . . . . . 10.4 Secure Scalar Product Computation . . . . . . . . . . Summary and Conclusions . . . . . . . . . . . . . . . . . . 11 Loterijen (Ruben van der Zwaan ) 11.1 Aanvallen . . . . . . . . . . . . . . . . . . . 11.2 Eigenschappen van loterijen . . . . . . . . . 11.3 Implementatie van een Elektronische Loterij 11.4 Technieken . . . . . . . . . . . . . . . . . . . 11.5 Samenvatting . . . . . . . . . . . . . . . . . 12 Digitale identificatie (R.A. van 12.1 Definities . . . . . . . . . . 12.2 Internetbankieren . . . . . . 12.3 Elektronische Overheid . . . 12.4 Een gevaarlijke chaos . . . . Samenvatting en conclusies . . . .

den Beukel ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 Hardeschijf versleuteling (Martin Warmer ) 13.1 Bestands versleuteling . . . . . . . . . . . 13.2 Een eerste oplossing . . . . . . . . . . . . . 13.3 Getweakte versleuteling . . . . . . . . . . . 13.4 LRW-AES . . . . . . . . . . . . . . . . . . 13.5 XTS-AES . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

53 53 56 58 59 60

. . . . .

61 61 62 67 71 73

. . . .

75 75 76 82 84

. . . . .

. . . . .

85 86 87 89 94 99

. . . . .

101 . 103 . 104 . 105 . 108 . 109

. . . . .

111 . 112 . 114 . 118 . 120 . 122

. . . . .

123 . 123 . 124 . 125 . 126 . 127

. . . . . . . . . . . . . .


vii

Samenvatting en conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 14 Valkuilen bij kleine exponenten in RSA (Jefrey Lijffijt ) 14.1 Introductie in het kraken van RSA . . . . . . . . . . . . 14.2 Oude bekenden . . . . . . . . . . . . . . . . . . . . . . . 14.3 Het kettingbreukalgoritme . . . . . . . . . . . . . . . . . 14.4 Het roosteralgoritme . . . . . . . . . . . . . . . . . . . . 14.5 Uit balans . . . . . . . . . . . . . . . . . . . . . . . . . . 14.6 Staat van de kunst . . . . . . . . . . . . . . . . . . . . . Samenvatting en conclusies . . . . . . . . . . . . . . . . . . . . 15 Een geheugen effici¨ ente achterdeur in 15.1 Elliptische krommen . . . . . . . . . 15.2 SETUP . . . . . . . . . . . . . . . . Samenvatting en conclusies . . . . . . . . .

. . . . . . .

RSA (Jos Roseboom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

131 131 132 133 134 135 135 136

) 137 . . . . . . . . 138 . . . . . . . . 142 . . . . . . . . 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: [email protected]

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 engineering2 . 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 SS . Each client has the corresponding public verification key SV hard-coded in the executable. When a user uses Skype for the first time3 , he or she will be asked to provide a username (A) and a password (PA ). The application will then generate an RSA keypair VA ,SA and send A, Hash4 (PA ) and VA to the Skype Central Server, using AES with a session key that is created using random functions from the user’s Operating System5 . The client can, and will check, that it is actually talking to the Skype Central Server6 . The Skype Central Server will check if the username is unique and otherwise acceptable under Skype naming rules7 . If this is the case, the server will store (A, Hash(Hash(PA )) in its user database. Next, it forms and signs an Identity Certificate for A, ICA , which contains, among other things8 , the Skype Central Server signature binding A and VA , {A, VA }SS and the key identifier of the SS . 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 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 SS 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’ 3

1.2 Skype

3

SkypeOut or SkypeIn. If the latter is the case, a SS with a modulus of 1536 bits will be used, otherwise a SS of 2048 bits will be used. After this process is done, ICA will be returned to A. 1.2.2

Establishing a call

When a Skype user (U1 ) calls another Skype user (U2 ), 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 nonces9 . The peers modify these received nonces in a standard way10 , sign it with their own RSA private signing key SU1 and SU2 respectively, and send the result back to the sender. After this, they exchange their Identity Certificates ICP1 and ICP2 . 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 users11 , both 32 bits12 . 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 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 10

4


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 program13 . 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]: Ã µ ¶! HM ACK (M ) = h (K ⊕ opad)kh (K ⊕ ipad)km , where k 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 supported14 . 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, svi and calculates the corresponding Diffie-Hellman public value, pvi . Last step in this phase is that the initiator creates a hash hvi of his pvi 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 svr and corresponding public value pvr and creates HMAC’s15 of all possible shared secrets, for a example for Retained Secret 1 rs1 : HM AC(rs1 , ”Responder”) Apart from rs1 and rs2 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 15

Specifically algorithms for hash, cipher, auth tag length, key agreement type and SAS See the subsection on HMAC’s for explanation

6


The responder now sends his pvr 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 pvi concatenated with all possible version information corresponds with the hash hvi it got earlier. If this is not the case, a man in the middle is present trying to do a bid-down-attack16 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: s0 = hash(DHSS | s1 | s2 | s3 | s4 | s5 ) 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 Keyi = HM AC(s0 , ”Initiator SRT P master key”) SRT P salsi = HM AC(s0 , ”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: rs1 = HM AC(s0 , ”retained secret”) If there already was an rs1 , this will become rs2 and a if an rs2 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(pvi | pvr | ”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


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

B x

g −−−y−→ g ←−−−−

K = g xy

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 x0 en y 0 (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. SIGA 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

M : x0 , y 0 0 gx gx −−−−0→ −−−−→ gy gy ←−−−− ←−−−−

A x

KA = g xy

0

B y 0

KB = g x y

Figuur 2.2: Man-In-The-Middle aanval op Diffie–Hellman

12

Sleuteluitwisseling

A x

B x

x

g , SIGA (g , B) −−−− −−−−−−−−−−−→ g y , SIGB (g y , A) ←−−−−−−−−−−−−−−

K = g xy

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

K = F (g ay ⊕ g bx )

B : b, g b gx −−−y−→ g ←−−−−

y 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 12 om het goed te hebben. Voor een succesvolle aanval moet de aanvaller dus met een grotere kans dan 12 slagen in de test-sessie. A : a, g a x

K = F (g ay ⊕ g bx )

M : ga gx −−−y−→ g ←−− −− g x0 −−−−→

B : b, g b y

K = F (g ay ⊕ g bx ) Ki = F (g ay ⊕ g bx )

Figuur 2.6: Unknown Key Share aanval op KEA

14

Sleuteluitwisseling

A : a, g a x

M : k, g ak gx − − − −→ y g g yk ←−−−−−x0←−−−− g −−−−→

K = F (g aky ⊕ g bx )

B : b, g b y

K = F (g ay ⊕ g bx ) K 0 = F (g aky ⊕ g bx )

Figuur 2.7: UKS aanval op KEA met unieke publieke sleutels

De aanval wordt als volgt uitgevoerd (zie ook figuur 2.6): • A en B beginnen een gewone sessie, M luistert mee. • Nadat M de tijdelijke publieke sleutels gezien heeft, begint hij ook een sessie met B, hij gebruikt hiervoor dezelfde tijdelijke publieke sleutel als A deed. • Hierdoor genereert B dezelfde sleutel voor zowel de sessie met A als die met M. • M ontfutselt nu een van de partijen de sessie-sleutel en gebruikt de andere, nog eerlijke sessie als test-sessie. • Omdat M de sessie-sleutel heeft slaagt hij met een kans 1 in de test-sessie. KEA is voldoet dus niet aan de AKE veiligheidseis (2.3). Hoewel het lijkt of de kwetsbaarheid van het protocol ligt in het feit dat M dezelfde publieke sleutel als A heeft geregistreerd, is dit niet het geval. M kan namelijk ook een publieke sleutel gebruiken die slechts gebaseerd is op die van A. Hiervoor gebruikt hij een geheime sleutel k, die gecombineerd wordt met de publieke sleutel van A, zoals te zien in figuur 2.7. Om nu te zorgen dat A en B weer dezelfde sleutel genereren voor de beide sessies bewerkt M op slinkse wijze de publieke sleutel die B naar A stuurt. Zelf kan M daarna geheel onschuldig een sessie met B starten en de tijdelijke publieke sleutel van A gebruiken om te zorgen dat B weer dezelfde sleutel berekent als die A heeft. Merk op dat in de sessie tussen A en B er twee verschillende sleutels gegenereerd zijn. Dit maakt echter voor het AKE experiment niet uit. 2.2.3

KEA+

Als versterking van KEA, stellen Lauter en Mityagin een verbeterde versie voor: KEA+ [LM06], zie figuur 2.9. De aanpassing lijkt slechts minimaal, maar heeft grote gevolgen voor de veiligheid van het protocol. Door namelijk de identiteit van de beide partijen mee te nemen in de berekening van de sleutel wordt voorkomen dat M op een onschuldige manier het voor elkaar kan krijgen

Samenvatting en conclusies

15

Kader 2.8: E-mailen met KEA Bij het versturen van e-mail is direct overleg met tijdelijke publieke sleutels niet mogelijk. Het KEA protocol is echter eenvoudig aan te passen om het toch te gebruiken voor het versturen van een beveiligde e-mail [NIS98]. Daarvoor is het in ieder geval nodig dat de publieke sleutel van de ontvangende partij op te vragen is uit een systeem of op een andere manier lokaal beschikbaar is. In plaats van de tijdelijke publieke sleutel van de ontvanger gebruikt de verzender twee keer de publieke sleutel. Als bijvoorbeeld A een bericht aan B stuurt dan wordt de sleutel K dus gemaakt met F (g ab ⊕ g bx ). om twee verschillende sessies dezelfde sleutel te laten hebben. M kan hierdoor geen eerlijke test-sessie meer opzetten met dezelfde sleutel als een gekraakte sessie. Ook het belang van de correctheid van de publieke sleutels valt hierdoor ook weg. De uitgebreide veiligheidsanalyse van Lauter en Mitygin in [LM06] laat zien dat het protocol veilig is tegen aanvallen en voldoet aan de veiligheidseisen zoals in dit hoofdstuk gedefinieerd, plus nog een aantal andere. Een vergelijkbare implementatie is het HMQV protocol [Kra05]. Dit is een uitbreiding op het efficiënte en veelgebruikte MQV protocol zoals onder andere beschreven in [BWM98], als ‘Protocol 6’.

Samenvatting en conclusies Sleuteluitwisseling is op het eerste gezicht eenvoudig op te lossen, maar de meest eenvoudige protocollen zoals Signed Diffie–Hellman zijn ook eenvoudig om aan te vallen. In het recente verleden zijn er nieuwe protocollen ontwikkeld die niet meer kwetsbaar zijn tegen deze nieuwe aanvallen, waarvan KEA een goed voorbeeld is, maar ook de veiligheidseisen die aan dergelijke protocollen worden gesteld worden ook steeds scherper. Dat is niet vreemd, want er wordt in die eisen ook rekening gehouden met de realiteit, buiten de testopstellingen. Zelfs als er een sleutel lekt of gestolen wordt moet zoveel mogelijk informatie alsnog beschermt zijn. Gelukkig bestaan er (op papier) enkele moderne protocollen zoals KEA+ die aan deze eisen voldoen.

A : a, g a x

B : b, g b gx −−−y−→ g ←−−−−

K = H(g ay , g bx , A, B)

y K = H(g ay , g bx , A, B)

Protocol 2.9: KEA+

16

Sleuteluitwisseling

Hoofdstuk 3 NTRU Door Mark Stobbe

Cryptografie staat nooit stil. De wereld moderniseert met de dag en de noodzaak voor nieuwe beveiligde cryptosystemen blijft groeien. Door onderzoek en experimenten worden er snellere aanvallen bedacht en slinkt de veiligheid van elk cryptosysteem. Natuurlijk is er niks aan de hand zolang het computationeel ondoenlijk is om het systeem te kraken, maar wat als het toch gebeurd? Het is altijd slim om naar nieuwe technieken te zoeken om betere systemen te bedenken. Andere toepassingen van cryptografie hebben misschien wel andere eisen. Sommige apparaten willen graag gebruik maken van cryptografie maar hebben misschien wel te weinig rekenkracht. Denk bijvoorbeeld aan RFID-cards of mobiele telefoons, waarbij energieverbruik en snelheid essentieel zijn. NTRU probeert hier een oplossing voor te bieden door met een snel cryptosysteem te komen. NTRU Cryptosystems Inc. is opgericht in 1996 door 4 wiskundige, Joseph H. Silverman, Jeffrey Hoffstein, Jill Pipher and Daniel Lieman van de Brown University. Dit bedrijf heeft een alternatief public-key cryptosysteem bedacht, genaamd NTRU (N th degree truncated polynomial ring). In plaats van de normale portie getallentheorie in bestaande cryptosystemen wordt er in NTRU gebruik gemaakt van polynomen. Er is al redelijk wat onderzoek gedaan op het gebied van polynomen en cryptografie en door bepaalde keuzes te maken ten aanzien van het soort polynomen kunnen er grote tijdwinsten worden geboekt [Sil00].

3.1

NTRU

Het cryptosysteem maakt gebruik van 3 parameters, N , p en q. N − 1 is de grootste exponent die in de polynomen voor kan komen. De p en q worden also moduli gebruikt, echter deze zijn niet begrensd tot de natuurlijke getallen, het kan bijvoorbeeld ook een polynoom zijn. Het zal blijken dat met het kiezen van een gunstige polynoom p de berekening kosten verminderen. 17

18

NTRU

Voor het versleutelen en ontsleutelen zijn er enkele basis operatie’s nodig op polynomen. Al deze operaties zullen plaats vinden in een ring van polynomen, R[X]/(xN − 1). Om de polynomen in deze ring te houden verloopt multiplicatie iets anders dan normaal. De exponenten die groter dan N zijn worden met N verminderd. Het optellen van twee polynomen is simpelweg het paar-gewijs optellen van de coëfficienten en zo werkt het reduceren met een modulo ook alleen op de coëfficienten. Om later weer het bericht te ontcijferen hebben we een inverse nodig van een polynoom. De inverse van een polynoom is gedefinieerd door: a ∗ a−1 = 1(modulo q). Hieronder staat een simpel voorbeeld waarbij alle elementaire operatie’s worden gebruikt. Hierbij is N = 3 en wordt er modulo q = 7 gerekend. Merk op dat het reduceren van de coëfficienten tussendoor ook toegestaan is, zolang het resultaat polynoom maar binnen de ring valt.

= = = =

(4 + 3x + 2x2 ) ∗ (4 + x + 6x2 ) (16 + 4x + 24x2 ) + (12x + 3x2 + 18x3 ) + (8x2 + 2x3 + 12x4 ) (16 + 4x + 24x2 ) + (12x + 3x2 + 18) + (8x2 + 2 + 12x) 36 + 28x + 35x2 1

{multiplicatie} {reduceren} {optellen} {modulo q}

Hoewel niet elk polynoom een inverse onder een bepaalde modulo q heeft, zijn er snelle technieken om hier achter te komen en de inverse te berekenen. Met een gunstige parameter keuze is er zelfs altijd een inverse te berekenen. Hoe dit precies werkt kan worden teruggevonden in de [Sil99], hier wordt ook een algoritme besproken voor het vinden van de inverse. Voor het voorbeeld gebruiken we N = 11, q = 32 en kiezen we p gelijk aan 2 + x. Het voorbeeld is gebasseerd op [Cry]. 3.1.1

Sleutelgeneratie

Bob wil gebruik maken van het NTRU cryptosysteem om met Alice te communiceren. De eerste stap is het genereren van een sleutelpaar. Voor de geheime sleutel van Bob kunnen we een willekeurig polynoom met een inverse modulo q nemen, maar we geven de voorkeur aan een iets intelligentere keuze. De geheime sleutel f van Bob heeft de vorm: f =1+p∗F F is een “klein” polynoom, dit betekent dat de coëfficienten van het polynoom niet al te groot moeten zijn. Om dit te garanderen kiezen we een getal dF en maken een polynoom met dF termen met coëfficient 1 en de rest van de coëfficienten zijn 0. Neem bijvoorbeeld dF = 4 en vervolgens kiezen we polynoom F = 1 + x4 + x7 + x9 . De geheime sleutel wordt dan: f = 3 + x + 2x4 + x5 + 2x7 + x8 + 2x9 + x10

3.1 NTRU

19

Verder berekenen we de inverse van f modulo q: fq−1 = 25 + 27x + 12x2 + 29x3 + 30x4 + 6x5 + 13x6 + 22x7 + 24x8 + 24x9 + 17x10 Voor de decryptie zouden we normaal ook de inverse van f modulo p moeten berekenen, maar door de keuze van f is deze stap triviaal. Immers f = 1 + p ∗ F (modulo p) is 1 en de inverse is dus ook 1. Vervolgens kiezen we opnieuw een “klein” polynoom G om zo de publieke sleutel h te berekenen. We kiezen dG = 5 en G = 1 + x + x4 + x6 + x10 . h = p ∗ fq−1 ∗ G Bob publiceert vervolgens zijn publieke sleutel: h = 15 + 11x + 9x2 + 18x3 + 20x4 + 12x5 + 25x6 + 20x7 + 19x8 + 24x9 + 30x10 . 3.1.2

Encryptie

Om een bericht naar Bob te versturen moet Alice haar bericht versleutelen door het volgende polynoom uit te rekenen: e=R∗h+M Hierbij is R weer een willekeurig gekozen “klein” polynoom en h de publieke sleutel van Bob. Voor een bericht van de vorm 01010100111, maken we het polynoom M = x + x3 + x5 + x8 + x9 + x10 . We kiezen weer een random getal dR = 4 om het polynoom R = 1 + x3 + x4 + x8 aan te maken. De berekening levert vervolgens een polynoom e op die naar Bob wordt verstuurd. e = 8 + 11x + 11x2 + 25x3 + 2x4 + 20x5 + 12x6 + 24x7 + 3x8 + 9x9 + 21x10 3.1.3

Decryptie

Bob wil vervolgens het bericht van Alice ontcijferen en moet daarvoor de cijfertekst met zijn geheime sleutel vermenigvuldigen. a=f ∗e Dit geeft een polynoom a die voldoet aan:

= = = =

f ∗e {versleutelen van e} f ∗ (R ∗ h + M ) {publieke sleutel h} −1 f ∗ (R ∗ (p ∗ f ∗ G) + M ) (f ∗ R ∗ p ∗ f −1 ∗ G) + (f ∗ M ) {f ∗ f −1 = 1} (R ∗ p ∗ G) + (f ∗ M )

20

NTRU

Aangezien R, G, f en M allemaal “kleine” polynomen zijn, zou de modulo q niks uit moeten maken. Ook p is “klein” gekozen en daarmee niet van invloed. Het is echter dus wel van belang om de parameters goed te kiezen. Vervolgens moet Bob het polynoom a reduceren modulo p om het bericht van Alice te verkrijgen. Het polynoom d komt vervolgens overeen met f ∗ m, reeds gereduceerd door p. Aangezien f (modulo p) triviaal was, zal Bob het bericht van Alice terugvinden. In het voorbeeld berekent Bob dus het polynoom a: a = 7 + 14x + 10x2 + 15x3 + 14x4 + 13x5 + 10x6 + 11x7 + 15x8 + 14x9 + 15x10 Vervolgens reduceert Bob het polynoom a modulo p en vindt het originele bericht van Alice. d = x + x3 + x5 + x8 + x9 + x10 In dit geval lagen de coëfficienten van a dichtbij elkaar in de buurt en heeft het reduceren door modulo q geen effect. Echter dit is niet altijd het geval en daarom moet soms een “centreer-algoritme” worden toegepast om de coëfficienten tussen het interval [0, q) te laten vallen.

3.2

Aanvallen

Huidige cryptosystemen, zoals RSA, berusten op de ondoenelijkheid van het factoriseren van de modulus. Echter NTRU berust op het factoriseren van een polynoom. Dit probleem hangt nauw samen met het lattice reduction en men heeft dan ook een aanval in de vorm van het shortest vector probleem geformaliseerd. Hieronder worden 3 aanvallen besproken op het NTRU cryptosysteem, waarvan de laatste specifiek voor NTRU is. 3.2.1

Meet-in-the-middle

Meet-in-the-middle is een bekende aanval op cryptosystemen waarbij twee of meer keer dezelfde versleuteling wordt toegepast. Echter in het geval van NTRU is deze aanval al mogelijk binnen het systeem. Zoals in sectie 3.1.1 is beschreven, wordt de publieke sleutel berekent uit h = p ∗ fq−1 ∗ G, dit komt overeen met f ∗ h = G. Wanneer het polynoom f nu in tweeën wordt gesplists, (f1 , f2 ), en vervolgens één deel overgebracht wordt naar de andere kant, f1 ∗h = G−f2 ∗h, dan kan er een aanval worden geformuleerd die telkens de paren links tegen de rechter paren wegstreept. Hiermee wordt een aanval op de geheime sleutel door de wortel van het totaal aantal mogelijke sleutels gereduceerd. 3.2.2

Meervoudige verzending

Een andere aanval is er één waarbij hetzelfde bericht M meerdere malen met dezelfde sleutel wordt verstuurd. Hoewel de uiteindelijke cijfertekst telkens verschillend zal zijn


21

door het vermenigvuldigen met een random gekozen polynoom R, kan men wel bepaalde delen achterhalen. In sectie 3.1.2 staat beschreven dat een bericht versleuteld wordt door een polynoom e te bereken die voldoet aan: e = R ∗ h + M . Wanneer dus hetzelfde bericht nogmaals wordt verstuurd, maar nu met R0 , kan de aanvaller berekenen dat: (e0 − e) ∗ h−1 = R0 − R. Hiermee kan hij telkens delen van R achterhalen en de aanvaller heeft al genoeg aan 4 à 5 berichten om R te achterhalen en daarmee dus ook het bericht. 3.2.3

Lattice reduction

Lattice reduction houdt zich bezig met het vinden van de korste vector in een lattice. Door het maken van een lattice waarbij de geheime sleutel wordt ontbonden kan door middel van een benaderingsalgoritme een gok gedaan worden naar de sleutel. Door een lattice te genereren uit de rijen van de 2N × 2N matrix van de vorm: µ ¶ A H 0 Q waarbij • A, een N × N identiteitsmatrix vermenigvuldigt met een constante α is • H, een N × N cyclish geroteerde matrix van de publieke sleutel h is • Q, een N × N identiteitsmatrix vermenigvuldigt met de modulus q is Het LLL algoritme van Lenstra-Lenstra-Lovász [AL82] kan in polynomiale tijd een benadering vinden, mits de instantie niet te lastig is en tevens verwachte lengte van de korste vector in de buurt zal liggen van de daadwerkelijke lengte van de korste vector. Er is meer onderzoek gedaan naar het gebruik van lattice reduction algoritme om de sleutel te factoriseren, meer hierover kan gevonden worden in [NHG]. De uiteindelijke beveiliging wordt momenteel gegarandeerd door twee variabele die aangeven hoeveel de lattice lijkt op een willekeurige lattice, waarmee verondersteld wordt dat het LLL algoritme een moeilijke tijd tegemoet gaat.

Samenvatting en conclusies De mensen achter NTRU hebben getracht om een snel cryptosysteem te bedenken en zijn een volledig andere richting ingeslagen dan de meeste conventionele systemen. Hierdoor zijn ze redelijk alleen in het veld en missen de grote ervaring met bestaande systemen. Echter de beschreven aanvallen zijn wel geformuleerd en zelfs uitgevoerd en zorgen er voor dat het systeem wankelt. NTRU is nog niet ten dode opgeschreven aangezien er nog onderzoek wordt gedaan naar betere parameter keuze en grotere polynomen. De voordelen qua besparing van rekenkracht wegen in sommige toepassingen misschien wel op tegen de veiligheid. Om toch enige veiligheid te bieden is ook een zeer goede parameter keuze vereist, waarbij dit systeem dus niet weggelegd is voor leken.

22

NTRU

Hoofdstuk 4 Microsoft Crypto API Door Pieter Hoogestijn

Rond het jaar 1995 is Microsoft begonnen aan het schrijven van de standaard Crypto API, een Application Programming Interface (API), die de software programmeur ondersteund in het oplossen van cryptografische problemen. De in 1996 gepubliceerde CryptoAPI 1.0 was een algoritme onafhankelijke Interface, geheel naar de syntax en architectuur van de overige Win32 API’s, die standaard in Windows95 en Windows-NT waren opgenomen. De eerste versie van de MS CryptoAPI werd eind 1996, voor het eerst als opgenomen in Internet Explorer 3.0. Enkele maanden later organiseerde Microsoft een Security Design Review (SDR) bijeenkomst, met als doel de CryptoAPI, zoals het er toen uitzag, voor te stellen aan het grote publiek en eventuele zwakheden te ontdekken. Als gevolg van de SDR bijeenkomst, en als gevolg van de voorddurende ontwikkeling op het gebied van cryptografie, werd in juli 1997 een update uitgebracht naar CryptoAPI 2.0. De tweede versie van de CryptoAPI beschikte over alle functionaliteiten die ook in versie 1.0 zaten, maar is daarnaast uitgerust met onderdeel voor het gebruik van certificaten tijdens beveiligde communicatie.

4.1

Cryptographic Service Providers

Om de programmeur te helpen bij het oplossen van cryptografische problemen, heeft Microsoft een achttal Cryptographic Service Providers (CSPs) opgenomen in de CryptoAPI. Deze CSPs zijn losstaande modulen, die ieder een aantal cryptografische functies en algoritmen bevatten. De programmeur kan één of meerdere CSPs laden bij het gebruik van de Crypto API. Op dit moment zijn de volgende CSPs in de CryptoAPI opgenomen:

23

24

Microsoft Crypto API

P rovider Base

Strong Enhanced AES DSS

Base DSS and Diffie-Hellman DSS and Diffie-Hellman/Schannel

Omschrijving Een breedte selectie aan cryptografische functies. Biedt onder andere het: MD5, SHA en RSA algoritme. Een uitbreiding op de Base Provider. Beschikbaar sinds Win2000. Een uitbreiding op de Base Provider, o.a.: langere sleutellengte. Een uitbreiding van de Enhanced Provider met het AES algoritme. Biedt o.a.: hashing, data-signing, signature verification door middle van SHA en Digital Signature Standard (DSS) Beidt hashing, data-signing door middel van DSS en Diffie-Hellman (DH) sleutel beheer. Beidt hashing, data-signing, signature verification en aantal protocollen zoals: SLL2, SLL3, PCT1 en TLS1.

Figuur 4.1: Microsoft Cryptographic Service Providers Alle CSPs bestaan uit minimaal twee bestanden, namelijk een Dynamic Link Library (DLL) en een Signature File. De Signature File wordt door de CryptoAPI gebruikt om regelmatig te controleren of er niet is geknoeid met de CSP modules. De sleutels die door de verschillende CSPs worden gegenereerd en gebruikt worden, per module en gebruiker, opgeslagen in een eigen key-database. Deze database is alleen beschikbaar voor de bijhorende CSP module en kan in beveiligde hardware worden opgeslagen, als de CSP module door deze hardware wordt ondersteund. Het eventueel uitwisselen van sleutels gebeurt aan de hand van key-blobs. Key-blobs zijn bestanden of register sleutels bestaande uit een standaard header, gevolgd door de sleutel. Applicaties kunnen niet bij de inhoud van deze key-blobs, welke zelf ook versleuteld kunnen zijn. Meer over key-blobs is te vinden op msdn.microsoft.com

4.2

Welke applicaties maken gebruik van de Crypto API

Steeds vaker hoor je in het nieuws dat er een USB-stick of laptop is gevonden met geheime informatie van de AIVD of het Ministerie van Defentie. Los van het feit dat het erg vervelend is voor de eigenaar die de spullen nodig heeft voor zijn werk, is er natuurlijk ook het risico dat kwaadwillende gebruikers er mee aan de haal gaan.

4.2 Welke applicaties maken gebruik van de Crypto API

25

Figuur 4.2: Microsoft CryptoAPI Architecture

4.2.1

Top Secret

Een oplossing voor het genoemde probleem zou zijn om alle geheime of privacygevoelige informatie versleuteld op te slaan, zodat in ieder geval de vinder de data niet kan gebruiken, zonder in het bezit te zijn van de geheime sleutel. Naast het feit dat het versleuteld opslaan van bestanden erg veilig is, is het ook nog eens enorm simpel. Veel de standaard applicaties zijn uitgerust met een functie om bestanden te versleutelen. Neem nu bijvoorbeeld de applicaties van het Microsoft Office pakket. Binnen het venster “Bestand opslaan (als)” kan de gebruiker, via de menuoptie “Extra”, aangeven of dat het bestand beveiligd moet worden. Vervolgens kan de gebruiker aangeven welk algoritme gebruiker moet worden, en hoelang de sleutel moet zijn. Niet alleen het Microsoft Office pakket maakt gebruikt de functionaliteiten van de Crypto API. In principe kan elke applicatie die in aanraking komt met het versleutelen van data, gebruik maken van de Crypto API. Het is daarom moeilijk te zeggen welke programma’s gebruik maakt van deze API. 4.2.2

Internet

Met de opkomst van internet, is er ook op dit gebied in toenemende mate een veilige overdracht van informatie vereist. In het bijzonder wachtwoorden, laat staan creditcard en bankgegevens, mogen natuurlijk nooit in plain-text worden overgestuurd. Voordat

26


deze gegevens worden verstuurd, worden ze daarom eerst door de browser versleuteld, en via een beveiligde verbinding naar de webserver van de ontvanger verstuurd. Deze probeert op haar beurt de gegevens te ontsleutelen, zodat ze verwerkt kunnen worden. Zoals in de eerste paragraaf al wordt genoemd, was Internet Explorer 3.0 de eerste applicatie die gebruik maakte van de functionaliteiten, aangeboden door de Crypto API. 4.2.3

Integriteit

Naast het versturen van geheime informatie, wordt de Crypto API ook gebruikt voor het controleren van zogenaamde certificaten, zodat de gebruiker bijvoorbeeld niet per ongeluk zijn pincode of creditcard nummer aan een derde partij prijsgeeft. Naast het controleren van de integriteit van bijvoorbeeld een handelspartner, wordt cryptografie ook gebruikt voor integriteitcontrole van allerlei andere zaken. Om aan te geven dat een bepaalde hardware driver volledig door Microsoft wordt ondersteund, wordt er voor alle ondersteunde drivers een certificaat uitgegeven. Door middel van dit certificaat wordt gegarandeerd dat er geen miscommunicatie kan optreden tussen de geleverde driver en het besturingssysteem. Als een programmeur zijn hardware drivers wil certificeren voor een bepaalde versie van het Windows besturingssysteem, moet hij de volgende stappen ondernemen: 1. Allereerst moet hij een certificaat aanvragen, zodat deze toegevoegd kan worden aan zijn software. Een dergelijk certificaat is onder andere te verkrijgen bij VeriSign, Inc. Natuurlijk moeten de uitgedeelde certificaten wel door Microsoft erkent worden. Als de drivers compatibel zijn bevonden wordt er een certificaat uitgegeven. 2. Als de programmeur een certificaat toegewezen heeft gekregen, moet hij alle bestanden in een CatalogFile opnemen. Dit kan met een applicatie als MakeCat, dat onderdeel is van de Microsoft CryptoAPI. 3. Vervolgens moet het certificaat gekoppeld worden aan de Catalog, dit kan door middel van de SignTool applicatie, dat eveneens onderdeel is van de CryptoAPI. 4. De CatalogFile bevat nu een digitale handtekening, maar moet nog even geverifieerd worden voordat hij gepubliceerd wordt. Meer over het aanvragen van een digitaal certificaat, is te vinden op de website: http://www.verisign.com/

4.3

NSA invloeden op de CryptoAPI

In Augustus van het jaar 1999, kwam de media met de mededeling dat er mogelijk een achterdeur in Microsoft Crypto API was ingebouwd. Deze achterdeur moest de NSA toegang geven tot de verschillende CSPs die in de API ge¨ımplementeerd zijn.

4.4 CryptoAPI in de aanval

27

Omdat alle CSPs gecertificeerd moeten zijn voor dat ze gebruikt kunnen worden, is het voor een programmeur, hacker of andere partij niet zonder meer mogelijk een CSP te vervangen of te wijzigen. Eerst moet hiervoor een certificaat aangemaakt worden, waardoor de programmacode altijd aan controle onderhevig is. Voordat een CSP wordt ingeladen in de Crypto API, wordt eerst gecontroleerd of deze is voorzien van een geldig certificaat. Dit gebeurt met de controle sleutel KEY. Deze sleutel is gevonden met behulp van debug-software, bijvoorbeeld zoals die door Microsoft gemaakt wordt. Naast de controle sleutel KEY, kwam echter ook een andere controlesleutel aan het licht. Deze sleutel droeg de verrassende naam: NSAKEY. Uit nader onderzoek van Andrew Fernandes van Cryptonym Corporation, is gebleken dat de NSAKEY nagenoeg de zelfde functie heeft als de KEY sleutel, maar alleen wordt gebruikt als de eerste controle met de KEY sleutel niet is gelukt. Een ander opmerkelijk verschil is dat de NSAKEY, in tegenstelling tot de KEY, niet van een certificaat is voorzien. Dit houdt in dat deze sleutel kan worden vervangen of gewijzigd, zonder dat de Crypto API hierdoor corrupt raakt. Door de aanwezigheid van de controle sleutel NSAKEY, zou de NSA wijzigingen kunnen toepassen op de CSPs van de Crypto API, zonder tussenkomst van Microsoft, en zelfs zonder goedkeuring van de eindgebruiker. Microsoft beweert echter de enige partij te zijn die beschikt over de privaatsleutel, die hoort bij de NSAKEY controlesleutel. Volgens Microsoft is de NSAKEY uitsluitend bedoeld als “backup” sleutel, die gebruikt kan worden als de privaatsleutel horende bij KEY verloren gaat. Daarnaast is het nog maar de vraag in hoeverre de NSA voordeel kan halen uit een controlesleutel die door iedereen aangepast kan worden. Naast de redenen waarom de NSA geen baad zou hebben bij een eigen controlesleutel, zijn er ook argumenten denkbaar waarbij de NSA wel degelijk belang heeft bij een dergelijke sleutel. Zo zouden veel organisaties verplicht gebruik moeten maken van kant en klare commerciële administratie software, maar met hulp van de NSA toch gebruik kunnen maken van een, niet publieke, cryptografische service. Natuurlijk is een eigen controlesleutel niet noodzakelijk voor het implementeren van eigen CSP’s, de NSA zou dit ook door Microsoft kunnen laten doen. Maar als er “gevoelige” algoritmen worden ge¨ımplementeerd, ligt dit toch iets anders. Daarnaast past het openbaar maken van algoritmen niet binnen het beveilingsbeleid van de NSA. Waarvoor de NSAKEY daadwerkelijk wordt gebruikt, zal hoogstwaarschijnlijk altijd een raadsel blijven.

4.4

CryptoAPI in de aanval

Hoewel het oorspronkelijke doel van de CryptoAPI het beschermen van privacygevoelige informatie is, kan het framework ook gebruikt worden om deze informatie bij een eindgebruiker los te krijgen. A.L. Young beschrijft in zijn artikel over “Cryptoviral extortion using Microsoft’s CryptoAPI”, hoe een hacker of andere criminele computergebruiker, doormiddel van enkele aanroepen van de Crypto API, een virus kan maken dat door middel van “Kidnapping” van bestanden probeert gevoelige informatie bij de gebruiker los te krijgen.

28


Het virus dat wordt beschreven maakt gebruikt van asymmetrische-, en symmetrische cryptografische algoritmen. Voor de asymmetrische algoritmen kan bijvoorbeeld RSA worden gebruikt. Voordat de aanval begint, maakt de aanvaller een sleutelpaar door middel van een asymmetrisch cryptografie algoritme. Van dit paar wordt de privaatsleutel versleuteld met het gekozen symmetrische algoritme en opgeslagen in een tekstbestand. De publiekssleutel wordt “hard coded” in het virus verwerkt. Het bestand met de versleutelde privaatsleutel, wordt samen met het virus naar het slachtoffer gestuurd. Eenmaal actief op de computer van het slachtoffer, genereert het virus een symmetrische Tripple-DES sleutel, en gebruikt het 3-DES algoritme om (alle) bestanden van het slachtoffer te versleutelen. De symmetrische 3-DES sleutel, wordt vervolgens versleuteld met de “hard coded” publiekssleutel. Het slachtoffer zit nu met een systeem vol versleutelde bestanden. Hij moet voldoen aan de eisen van de aanvaller, om beschikking te krijgen over de sleutel om de bestanden te ontsleutelen. Als het slachtoffer de eisen van de aanvaller heeft ingewilligd, krijgt het slachtoffer de symmetrisch sleutel die is gebruikt om de privaatsleutel te versleutelen. Met deze sleutel kan het slachtoffer de privaat sleutel ontsleutelen, waardoor hij ook de 3-DES sleutel kan ontsleutelen. Met de ontsleutelde 3-DES sleutel, kan het slachtoffer zijn bestanden weer leesbaar maken. Het virus dat A.L. Young wordt beschreven is niet zo zeer een product dat absoluut niet zonder Crypto API zou kunnen wordt gemaakt. Maar het bestaan van een dergelijk framework maakt de technische drempel substantieel lager.

Hoofdstuk 5 OpenPGP Door Sander Schuckman

Pretty Good Privacy (afgekort PGP) is een cryptosysteem waarmee berichten kunnen worden ondertekend en versleuteld. De eerste versie van PGP werd in 1991 ontwikkeld door Phil Zimmermann [Zim95]. Zimmermann schreef PGP zodat mensen veilig BBS systemen (een voorloper van het Internet forum) konden gebruiken. Al gauw werd PGP encryptie ook gebruikt op het Internet en voor het veilig communiceren via email. Doordat PGP encryptie wereldwijd steeds meer gebruikt werd, waren er veel mensen die software wilden schrijven waarbij ook PGP encryptie kon worden gebruikt. In 1997 besloot Zimmermann dat er een open standaard voor PGP encryptie moest komen. Deze standaard werd OpenPGP genoemd. De GNU Privacy Guard (afgekort GnuPG of GPG) is een gratis, open source implementatie van de OpenPGP standaard. In dit hoofdstuk zullen we het steeds hebben over OpenPGP, maar in plaats daarvan kan ook iedere implementatie worden gelezen die aan de OpenPGP standaard voldoet. In sectie 5.1 wordt allereerst de werking van encryptie zoals gebruikt in OpenPGP en het sleutelbeheer besproken. In sectie 5.2 wordt het berichtformaat van OpenPGP besproken. Niet alle details zullen daar behandeld worden, maar er wordt wel wat dieper ingegaan op de Cipher Feedback mode die door OpenPGP gebruikt wordt. Vervolgens worden in sectie 5.3 twee aanvallen op deze Cipher Feedback mode besproken.

5.1 5.1.1

Werking Encryptie

Voor de encryptie van berichten maakt OpenPGP gebruik van een hybride cipher . Dit is een combinatie van symmetrische en public-key cryptografie. Het bericht wordt versleuteld met symmetrische encryptie en vervolgens wordt de gebruikte symmetrische sleutel versleuteld met public-key encryptie. 29

30

OpenPGP

Als Alice een bericht wilt versturen naar Bob dan genereert ze eerst een willekeurige symmetrische sleutel en versleutelt ze het bericht met deze sleutel. Omdat deze sleutel voor ieder bericht verschillend is wordt dit ook wel de sessiesleutel genoemd. Vervolgens versleutelt ze de sessiesleutel met de publieke sleutel van Bob en stuurt het versleutelde bericht samen met de versleutelde sessiesleutel naar Bob. Bob ontsleutelt de versleutelde sessiesleutel met zijn geheime sleutel en kan vervolgens ook het bericht ontsleutelen. Het voordeel van deze hybride cipher over alleen symmetrische of alleen public-key encryptie is dat symmetrische encryptie veel sneller is dan public-key encryptie. Symmetrische encryptie is vaak wel een factor 1000 sneller. Door het gebruik van public-key encryptie heb je niet het probleem van het uitwisselen van de sleutels zoals bij symmetrische encryptie. In feite wordt public-key cryptografie gebruikt om de symmetrische sleutels veilig te kunnen uitwisselen. 5.1.2

Sleutelbeheer

Bij public-key cryptografie is het heel belangrijk dat de publieke sleutel van een persoon ook daadwerkelijk van die persoon is. Een aanvaller Oscar kan zijn sleutel naar Bob sturen als zijnde de publieke sleutel van Alice. Als Bob een bericht wilt versturen naar Alice dan gebruikt hij dus die sleutel in de veronderstelling dat die van Alice is en dat alleen zij het bericht kan ontsleutelen, maar het is nu Oscar die het bericht kan ontsleutelen. Als Oscar het bericht vervolgens ook nog doorstuurt naar Alice kan Oscar alle berichten van Bob naar Alice lezen, zonder dat ze dit ooit te weten komen. Voordat Bob de publieke sleutel van Alice accepteert zal hij dus eerst moeten controleren of die sleutel ook echt van Alice is. Als Bob en Alice elkaar persoonlijk kennen dan kan Alice haar sleutel persoonlijk aan Bob overhandigen. Bob zou ook de sleutel via de telefoon kunnen controleren door middel van de fingerprint van de sleutel. De fingerprint is een hash van de sleutel en is uniek voor iedere sleutel. Bob belt Alice op en vraagt haar de fingerprint van haar sleutel voor te lezen. Als die hetzelfde is als de fingerprint van de sleutel die hij heeft van Alice, dan weet hij dus dat die sleutel echt van Alice is. Als je met veel verschillende personen communiceert is het onhandig om alle sleutels handmatig te controleren. Op het Internet verstuur je vaak berichten naar personen over de hele wereld, die je niet persoonlijk kent. Het is dus niet mogelijk om de sleutels persoonlijk te overhandigen. Ook als Alice de sleutel van Carol controleert via de telefoon dan kan Oscar zich aan de telefoon als Carol voor doen. Alice heeft Carol nog nooit ontmoet en kan dus niet weten of ze wel echt met Carol spreekt. In OpenPGP wordt het controleren van de sleutels daarom overgelaten aan andere personen, waarbij je erop vertrouwt dat die personen de sleutels goed gecontroleerd hebben. Alice kent bijvoorbeeld Bob en heeft de sleutel van Bob gecontroleerd en zet nu met haar geheime sleutel een handtekening op de sleutel van Bob. Hiermee verklaart ze dat de sleutel van Bob geldig is. Bob kent ook Carol en hij heeft haar sleutel ook gecontroleerd en ondertekend. Alice vertrouwt Bob en weet dat hij de sleutels goed controleert. Als Alice nu een bericht naar Carol wilt versturen ziet ze Bob zijn handtekening op de sleutel van Alice en concludeert daarmee dat Alice haar sleutel inderdaad geldig is.

5.2 Berichtformaat

31

Zo ontstaat er dus een netwerk van personen die elkaars sleutel hebben gecontroleerd. Alice kan de sleutel van Dave gebruiken als er een pad is van gecontroleerde sleutels tussen Alice en Dave, waarbij Alice iedereen op dit pad vertrouwt. Daarom wordt dit in OpenPGP ook wel een web of trust genoemd.

5.2

Berichtformaat

OpenPGP is een open standaard en het berichtformaat dat door OpenPGP gebruikt wordt staat beschreven in RFC2440 [CDFT98]. Een OpenPGP bericht bestaat uit packets en ieder packet bevat een header die de type en lengte van het packet aangeeft. De body van een packet bevat de data en hangt af van het type van het packet. Deze data kan ook weer bestaan uit andere packets. Een typisch OpenPGP bericht ziet er bijvoorbeeld als volgt uit. Allereerst wordt het bericht in een Literal Data Packet gestopt. Als het bericht ook ondertekent is wordt de handtekening in een Signature Packet gestopt. Voor de encryptie wordt meestal eerst nog compressie toegepast. Beide packets worden gecomprimeerd en in een Compressed Data Packet gestopt. Dit packet wordt vervolgens versleuteld met een symmetrisch encryptiealgoritme en het resultaat wordt in een Symmetrically Encrypted Data Packet gestopt. Als laatst wordt de gebruikte sessiesleutel nog versleuteld met de publieke sleutel van de ontvanger en dit wordt in een Public Key Encrypted Session Key Packet gestopt. Het Public Key Encrypted Session Key Packet en het Symmetrically Encrypted Data Packet worden vervolgens samen naar de ontvanger gestuurd. Als een bericht meerdere ontvangers heeft wordt de sessiesleutel met de geheime sleutel van iedere ontvanger versleuteld en het bericht bevat dan meerdere versleutelde sessiesleutels. Als je zelf het bericht later ook nog wilt kunnen ontsleutelen zul je de sessiesleutel dus ook met je eigen geheime sleutel moeten versleutelen. Ook is het mogelijk om de sessiesleutel met een symmetrische encryptiealgoritme gebaseerd op een wachtwoord te versleutelen, zodat de sessiesleutel en dus het bericht ook met dit wachtwoord te ontsleutelen is. 5.2.1

Cipher Feedback mode

OpenPGP maakt gebruik van een symmetrisch encryptiealgoritme met een vaste invoergrootte. Als je een bericht wilt versleutelen wat langer is dan de invoergrootte wordt het bericht daarom in blokken verdeeld, waarbij de grootte van ieder blok gelijk is aan de invoergrootte, ook wel de blokgrootte genoemd. Vervolgens wordt ieder blok van het bericht apart versleuteld tot een blok van de cijfertekst. Het nadeel hiervan is dat bij de versleuteling van twee gelijke blokken klaretekst, de blokken cijfertekst ook gelijk zijn. Bij de Cipher Feedback (CFB) mode wordt daarom ieder blok van de klaretekst gecombineerd met een deel van de cijfertekst, zodat patronen in de klaretekst niet zichtbaar zijn in de cijfertekst. Stel dat EK (·) de encryptie met sleutel K van het symmetrische encryptiealgoritme is met een blokgrootte van 8 bytes. De klaretekst die versleuteld wordt is M =

32

OpenPGP

(M1 , . . . , Mn ) en bestaat uit n blokken van ieder 8 bytes. De CFB mode gebruikt een willekeurig blok van 8 bytes als de initialisatievector IV . De cijfertekst C = (C1 , . . . , Cn ) wordt dan als volgt verkregen. C1 = EK (IV ) ⊕ M1 C2 = EK (C1 ) ⊕ M2 .. . Ci = EK (Ci−1 ) ⊕ Mi Er wordt dus steeds een blok van de cijfertekst verkregen door de encryptie van het vorige cijfertekstblok te XOR-en met een blok van de klaretekst. De initialisatievector wordt hierbij gebruikt om dit proces op te starten. Bij de decryptie wordt een blok van de klaretekst weer verkregen door een blok van de cijfertekst te XOR-en met de encryptie van het vorige cijfertekstblok. Gegeven de cijfertekst C = (C1 , . . . , Cn ) wordt de klaretekst M = (M1 , . . . , Mn ) dan weer als volgt verkregen. M1 = EK (IV ) ⊕ C1 M2 = EK (C1 ) ⊕ C2 .. . Mi = EK (Ci−1 ) ⊕ Ci 5.2.2

OpenPGP Cipher Feedback mode

OpenPGP gebruikt een variant van de CFB mode. In plaats van een willekeurige initialisatievector gebruikt OpenPGP een initialisatievector die bestaat uit allemaal nullen. Ook worden er 10 willekeurige bytes aan het begin van de klaretekst toegevoegd. Er wordt eerst een willekeurig blok R van 8 bytes versleuteld en dit wordt gebruikt als eerste blok van de cijfertekst. Vervolgens worden de laatste twee bytes van R nog een keer versleuteld en gebruikt als het tweede blok van de cijfertekst. De klaretekst die versleuteld wordt is weer M = (M1 , . . . , Mn ) en ~0 is een blok bestaande uit allemaal nullen en k is de concatenatieoperator. Met X[i,j] worden bytes i en j van X bedoeld en met X[i−j] bytes i tot en met j. De cijfertekst C = (C1 , . . . , Cn+2 ) wordt dan als volgt verkregen. C1 C2 C3 C4 Ci

= = = = .. . =

EK (~0) ⊕ R EK (C1 )[1,2] ⊕ R[7,8] EK (C1[3−8] k C2[1,2] ) ⊕ M1 EK (C3 ) ⊕ M2 EK (Ci−1 ) ⊕ Mi−2

Het cijfertekstblok C2 is hier nu ook maar 2 bytes groot. De laatste 8 bytes van de encryptie van de willekeurige 10 bytes wordt gebruikt als de initiële waarde om het eerste klaretekstblok mee te versleutelen en wordt dus gebruikt

5.3 Aanvallen

33

als een soort initialisatievector zoals bij de standaard CFB mode. Door de laatste twee bytes van het willekeurige blok R te herhalen kan tijdens het ontsleutelen snel worden gekeken of de gebruikte sessiesleutel geldig is. Nadat alleen C1 en C2 ontsleuteld zijn, kan worden gekeken of de laatste twee bytes gelijk zijn. Is dit niet het geval dan is de gebruikte sessiesleutel incorrect en kan het decryptieprocess afgebroken worden. In sectie 5.3.2 zullen we zien dat juist op deze snelle controle een aanval mogelijk is.

5.3 5.3.1

Aanvallen

Gekozen-cijfertekstaanval

De aanval die in deze sectie wordt beschreven is een gekozen-cijfertekstaanval op de CFB mode en is bedacht door Katz en Schneier [KS00]. Bij de aanval gaan we ervan uit dat we een cijfertekst C hebben onderschept en dat we daarvan de klaretekst M willen achterhalen. Hierbij hebben we ook de beschikking over een decryptieorakel waarnaar we een cijfertekst C 0 kunnen sturen en het orakel geeft ons dan de decryptie M 0 van die cijfertekst. Er moet dan wel gelden dat C 0 6= C, anders zou de aanval wel erg triviaal zijn. De aanval gaat nu als volgt te werk. Gegeven de cijfertekst C = (C1 , . . . , Cn ) kan het klaretekstblok Mi als volgt worden bepaald. 1. Kies een random blok D. 2. Stuur de cijfertekst C 0 = (C1 , C2 , Ci+1 , D) naar het orakel. 3. Ontvang de decryptie M 0 = (M10 , . . . , M40 ), waarbij M40 = D ⊕ EK (Ci+1 ). 4. Bereken vervolgens Mi = M40 ⊕ D ⊕ Ci+2 . De gehele klaretekst M kan nu worden bepaald door de volgende cijfertekst naar het orakel te sturen. C 0 = (C1 , C2 , D1 , C3 , D2 , . . . , Cn−1 , Dn−2 ) Bij de decryptie hiervan wordt ieder blok Ci van de originele cijfertekst ontsleuteld door te XOR-en met de encryptie van een random blok. De decryptie van C 0 zal dus niet lijken op de originele klaretekst. Haalbaarheid Bij de aanval gingen we ervan uit dat we konden beschikken over een decryptieorakel. Als OpenPGP wordt gebruikt om email mee te versleutelen is het mogelijk om over zo’n decryptieorakel te beschikken. Stel dat Alice een versleutelde email heeft ontvangen en Oscar heeft dit bericht onderschept. De email bestaat uit een versleutelde sessiesleutel en het bericht versleuteld met die sessiesleutel. Het versleutelde bericht is dus de cijfertekst C en Oscar wil daarvan de klaretekst M achterhalen.

34

OpenPGP

Oscar construeert de cijfertekst C 0 zoals beschreven en stuurt die samen met de versleutelde sessiesleutel van de onderschepte email naar Alice. Door de versleutelde sessiesleutel te hergebruiken zal tijdens de decryptie door Alice dezelfde symmetrische sleutel worden gebruikt. Alice opent vervolgens haar emailprogramma en haar emailprogramma ontsleuteld automatisch de email van Oscar, maar doordat de cijfertekst veranderd is lijkt het bericht op een willekeurige reeks letters. Ze denkt dat er waarschijnlijk wat misgegaan is tijdens het versturen en stuurt daarom een email terug naar Oscar met de vraag of Oscar het opnieuw zou kunnen versturen en ze quote hierbij het ‘corrupte’ bericht. Oscar ontvangt zo de decryptie van C 0 en kan hiermee dan de klaretekst bepalen. Jallad, Katz en Schneier [JKS02] geven een implementatie van de aanval op PGP en GnuPG. De aanval is succesvol als er tijdens de encryptie geen compressie wordt toegepast. Als tijdens de encryptie de klaretekst eerst nog wordt gecomprimeerd maakt dit de aanval iets gecompliceerder. Als gecomprimeerde data wordt veranderd is het vaak niet meer mogelijk om tijdens de decompressie de originele data weer te reconstrueren. Bij de aanval worden er willekeurige blokken tussen de cijfertekst gestopt en tijdens de decryptie ervan levert dit een willekeurige gecomprimeerde klaretekst op. Er is dus een grote kans dat de decompressie van de gecomprimeerde klaretekst niet slaagt, waardoor de klaretekst niet verkregen wordt. De aanval is nog steeds mogelijk door de bits van de header van het Compressed Data Packet te veranderen in een Literal Data Packet. Hierdoor wordt tijdens de decryptie de decompressiestap overgeslagen en de gecomprimeerde klaretekst wordt door het emailprogramma aan Alice getoond. Dit zal dus helemaal niet meer lijken op de oorspronkelijke klaretekst en als ze het terugstuurt naar Oscar kan hij hieruit de gecomprimeerde klaretekst van het onderschepte bericht bepalen. Door dit dan weer te decomprimeren kan hij dan de klaretekst M achterhalen. Helaas slaagt deze methode niet op GnuPG, omdat GnuPG voor de decryptie een hash van de klaretekst berekent en die gebruikt om het resultaat van de decryptie te kunnen controleren. Bij de geconstrueerde cijfertekst zal deze controle niet slagen, waardoor de aanval niet mogelijk wordt. Deze controle staat niet beschreven in de OpenPGP standaard en is dus een extensie op de standaard. Als een implementatie precies de OpenPGP standaard op zou volgen, dan zal bij die implementatie de aanval ook bij het gebruik van compressie slagen. Preventie De aanval is op een aantal manieren te voorkomen. Je zou ervoor kunnen kiezen om ‘corrupte’ berichten nooit terug te sturen. Dit is niet een echte oplossing van het probleem. Het zou kunnen zijn dat het bericht echt corrupt is geraakt tijdens het versturen. Ook zou Oscar door middel van social engineering Alice toch nog kunnen overhalen het bericht terug te sturen. Omdat Oscar de versleutelde sessiesleutel van de onderschepte email hergebruikt, zou het emailprogramma van Alice kunnen controleren of de sessiesleutel al een keer gebruikt is. Dit kan door de hash van de sessiesleutel op te slaan. Door de hash van de sessiesleutels op te slaan in plaats van de sessiesleutels zelf, voorkom je dat een aanvaller

5.3 Aanvallen

35

die toegang krijgt tot de bestanden van Alice de sessiesleutels kan verkrijgen en al haar vorige communicatie kan ontsleutelen. Het probleem hierbij is dat als je veel email verstuurt de opslag hiervan onhandig is. Zoals al werd opgemerkt slaagde de aanval bij het gebruik van compressie niet bij GnuPG, omdat er door middel van een hash nog een extra controle op de juistheid van de klaretekst werd uitgevoerd. Dit kunnen we natuurlijk ook gebruiken om ervoor te zorgen dat de aanval ook zonder het gebruik van compressie niet meer mogelijk is. Voor de encryptie wordt een hash van de klaretekst berekend. Die hash wordt aan de klaretekst toegevoegd en wordt dus samen met de klaretekst versleuteld. Bij de decryptie wordt de cijfertekst en dus ook de hash weer ontsleuteld en vervolgens wordt de hash van het versleutelde resultaat berekend en gekeken of die hetzelfde is als de ontsleutelde hash. Als de cijfertekst veranderd is dan zal deze controle niet slagen en het programma kan dan een waarschuwing geven. Een gebruiker zal dan het bericht terugsturen, waardoor de aanval niet meer mogelijk wordt. 5.3.2

Gekozen-cijfertekst-validatieaanval

In deze sectie wordt een gekozen-cijfertekst-validatieaanval beschreven op de OpenPGP CFB mode. Deze aanval is bedacht door Mister en Zuccherato [MZ05]. Bij een gekozencijfertekst-validatieaanval kunnen we een cijfertekst construeren en bepalen of dit een geldig versleuteld bericht is. We gaan ervan uit dat we weer de beschikking hebben over een orakel dat gegeven een cijfertekst C bepaalt of de controle op de herhaalde bytes zoals beschreven in sectie 5.2.2 geslaagd is. Is dat het geval dan weten we dat voor C geldt C1[7,8] ⊕ EK (~0)[7,8] = C2 ⊕ EK (C1 )[1,2] Als EK (C1 )[1,2] bekend is kunnen we daarmee EK (~0)[7,8] bepalen en omgekeerd als EK (~0)[7,8] bekend is kunnen we daarmee EK (C1 )[1,2] bepalen. Bij de aanval construeren we eerst een cijfertekst waarbij EK (C1 )[1,2] bekend is om zo EK (~0)[7,8] te bepalen. Vervolgens kunnen we een andere cijfertekst construeren waarmee we EK (C1 )[1,2] kunnen bepalen en daarmee kunnen we dan de eerste twee bytes van een willekeurig klaretekstblok mee achterhalen. Bij de aanval gaan we ervan uit dat de aanvaller een cijfertekst C heeft onderschept en dat hij de eerste twee bytes van de klaretekst M1[1,2] kent. De aanvaller kan nu als volgt EK (~0)[7,8] bepalen. 1. D is een getal van twee bytes met waarde nul. 2. Stuur cijfertekst C 0 = (C1[3−8] k C2 , D, C3 , C4 , . . . ) naar het orakel. 3. Slaagt de controle dan geldt C2 ⊕ EK (~0)[7,8] = D ⊕ EK (C1[3−8] k C2 )[1,2] Anders, verhoog D met één en ga naar stap 1.

36

OpenPGP

Omdat M1[1,2] bekend is kan EK (C1[3−8] k C2 )[1,2] bepaald worden met M1[1,2] ⊕C3[1,2] . Omdat alle mogelijke waarden van D worden geprobeerd zal de controle een keer slagen en dan kan in stap 3 EK (~0)[7,8] bepaald worden. Voor bepalen van EK (~0)[7,8] moeten we dus maximaal 216 cijferteksten naar het orakel sturen. Nu EK (~0)[7,8] bekend is kan als volgt de eerste twee bytes van een klaretekstblok Mi[1,2] als volgt worden bepaald. 1. D is een getal van twee bytes met waarde nul. 2. Stuur de cijfertekst C 0 = (Ci+1 , D, C3 , C4 , . . . ) naar het orakel. 3. Slaagt de controle dan geldt Ci+1[7,8] ⊕ EK (~0)[7,8] = D ⊕ EK (Ci+1 )[1,2] Anders, verhoog D met één en ga naar stap 1. 4. Dan Mi[1,2] = EK (Ci+1 )[1,2] ⊕ Ci+2[1,2] . Alle mogelijke waarden van D worden geprobeerd en de controle zal dus een keer slagen. Omdat EK (~0)[7,8] nu bekend is kan in stap 3 EK (Ci+1 )[1,2] bepaald worden. Met EK (Ci+1 )[1,2] kan vervolgens Mi[1,2] bepaald worden. We moeten ook weer 216 cijferteksten naar het orakel sturen om de eerste twee bytes van een willekeurig klaretekstblok te bepalen. Haalbaarheid Bij de aanval gingen we ervan uit dat de eerste twee bytes van de klaretekst bekend zijn. De klaretekst zelf is ook weer een OpenPGP packet en de headers daarvan zijn vrij voorspelbaar. De eerste byte bevat het type van het packet en dit kan een Literal Data Packet of een Compressed Data Packet zijn. De tweede byte bevat de lengte van het packet of in het geval van een Compressed Data Packet het gebruikte compressiealgoritme. Er zijn dus maar een klein aantal mogelijkheden en de aanvaller kan de eerste twee bytes van de klaretekst bepalen door een aantal mogelijkheden uit te proberen. Ook moeten we weer de beschikking hebben over een orakel. De methode bij de gekozen-cijfertekstaanval van de vorige sectie kunnen we nu niet gebruiken, omdat een menselijke gebruiker niet 64.000 berichten gaat ontsleutelen. In plaats daarvan kunnen we voor ons orakel een OpenPGP server gebruiken. Naar deze server kunnen met OpenPGP versleutelde berichten verstuurd worden, waarna de berichten worden ontsleuteld en verwerkt. Als een aanvaller een bericht onderschept wat naar deze server is gestuurd, dan kan hij een cijfertekst construeren en die naar de server sturen. Als de controle op de herhaalde bytes niet slaagt, dan zal de server een foutmelding teruggeven. Slaagt de controle wel, dan wordt cijfertekst geaccepteerd en zo kan de aanvaller dus de eerste twee bytes van een klaretekstblok achterhalen. Bij de controle op de herhaalde bytes wordt het decryptieproces meteen afgebroken als de bytes niet hetzelfde zijn. Geeft de server geen informatie over het wel of niet slagen van de controle, dan is het nog steeds mogelijk om te bepalen of de controle geslaagd is door de tijd van het decryptieproces te meten.


37

Bij een blokgrootte van 8 bytes kan een aanvaller 25% van de klaretekst achterhalen en bij een blokgrootte van 16 bytes 12,5% van de klaretekst. Als de klaretekst gewone Nederlandse tekst is, heeft dit grote gevolgen voor de veiligheid van het systeem. Als tijdens de encryptie weer compressie wordt gebruikt, dan kan een aanvaller 25% van de de gecomprimeerde klaretekst achterhalen. Het is dan niet zeker of het dan ook mogelijk is om een gedeelte van de ongecomprimeerde cijfertekst te achterhalen. Daarom wordt de aanval in de praktijk niet gauw uitgevoerd. Preventie De aanval is gemakkelijk te voorkomen door de snelle controle op de herhaalde bytes zoals beschreven in de OpenPGP standaard niet te implementeren. Door geen foutmelding te geven en het decryptieproces niet eerder af te breken kan een aanvaller niet over een orakel beschikken en de aanval is dan niet meer mogelijk. Het berekenen van een hash van de klaretekst, zoals werd gedaan om de gekozencijfertekstaanval van de vorige sectie te voorkomen, heeft bij deze aanval geen effect. De hash wordt gecontroleerd nadat het hele bericht ontsleuteld is, terwijl de herhaalde bytes al gecontroleerd worden nadat alleen de eerste twee blokken ontsleuteld zijn. Door te tijd van het decryptieproces te meten is het dan nog steeds mogelijk om te bepalen of de controle wel of niet geslaagd is.

Samenvatting en conclusies Met OpenPGP kunnen berichten worden ondertekend en versleuteld om zo beveiligde communicatie mogelijk te maken. Bij OpenPGP wordt een hybride cipher gebruikt die de snelheid van symmetrische encryptie combineert met het gemak van het uitwisselen van de sleutels bij public-key cryptografie. Voor controleren van de publieke sleutels maakt OpenPGP gebruik van een web of trust waarbij je op anderen vertrouwt om de sleutels te controleren. OpenPGP maakt gebruik van de Cipher Feedback mode voor encryptie. Omdat een aanvaller de mogelijkheid heeft om de decryptie van een speciaal geconstrueerde cijfertekst te verkrijgen, maakt dit een gekozen-cijfertekstaanval op de CFB mode mogelijk en een aanvaller kan zo de klaretekst van een versleuteld bericht achterhalen. Doordat OpenPGP tijdens de decryptie een snelle controle uitvoert waarbij twee bytes van de klaretekst herhaald worden, maakt dit een tweede aanval mogelijk waarbij een aanvaller de eerste twee bytes van een klaretekstblok kan achterhalen als hij weet of de controle op een speciaal geconstrueerde cijfertekst geslaagd is.

38

OpenPGP

Hoofdstuk 6 Side Channel Attacks Door Kasper Brink

Sinds de tweede helft van de jaren ’90 wordt er steeds meer onderzoek gedaan naar een nieuw soort cryptografische aanval, de side channel attack. Bij traditionele cryptanalyse kijkt een aanvaller alleen naar de cijferteksten en/of klareteksten die een cryptografisch algoritme verwerkt, en probeert daaruit de geheime sleutel te achterhalen. Bij side channel analyse daarentegen richt de aanvaller zich op één specifieke implementatie van een algoritme in hardware of software: hierbij zijn er vaak fysieke kanalen te vinden, side channels, waarlangs informatie over de interne toestand van het cryptosysteem naar buiten “lekt”. Door bijvoorbeeld het stroomgebruik of de looptijd van een cryptografische bewerking te meten, kan de aanvaller veel efficiënter achter sleutelinformatie komen dan wanneer hij het algoritme rechtstreeks zou aanvallen. Een overzicht van dit onderwerp is te vinden in [QK02, LOU]. In dit hoofdstuk zullen we eerst de ideeën achter side channel analyse bespreken. Hierbij onderscheiden we twee categorieën: simpele analyses en differentiële analyses. Vervolgens zullen we van beide soorten een analyse in detail beschrijven.

6.1 6.1.1

Achtergrond

Twee manieren om een cryptosysteem te beschouwen

De gedachte achter side channel analyse is dat er twee verschillende manieren zijn om naar een cryptosysteem te kijken. Allereerst is zo’n systeem, bijvoorbeeld een symmetrisch of asymmetrisch encryptiealgoritme, of een digitale handtekening, te beschouwen als een wiskundige functie. Deze functie krijgt een bericht en een geheime sleutel en beeldt die af op een ander bericht (de versleuteling, ontsleuteling of handtekening). De aanvaller heeft de beschikking over een aantal van de ingevoerde en/of geproduceerde berichten, en probeert daaruit de sleutel te achterhalen. In het verleden waren cryptografische aanvallen altijd gericht op het “breken van de wiskunde”, en hiervoor zijn 39

40

Side Channel Attacks

krachtige technieken ontwikkeld, bijvoorbeeld differentiële en lineaire cryptanalyse tegen blokversleutelingen als DES. Toch zijn zulke aanvallen, ook als ze efficiënter zijn dan een brutekrachtaanval, in de praktijk vaak niet bruikbaar, omdat ze nog erg veel rekenwerk vergen, of onrealistische hoeveelheden klaretekst of cijfertekst nodig hebben. In de loop van de jaren ’90 groeide in de cryptografische gemeenschap het besef dat je een cryptosysteem ook kunt beschouwen als een fysieke implementatie van een wiskundig algoritme. In de praktijk worden cryptografische bewerkingen altijd uitgevoerd door een machine – of dit nu in software of hardware gebeurt maakt in dit geval weinig uit. Het beeld van de pure wiskundige functie die invoerberichten afbeeldt op uitvoerberichten is nu onvolledig: het uitrekenen van deze functie verbruikt ook stroom, duurt een aantal klokcycli, maakt soms gebruik van bepaalde processor-caches, produceert warmte en electromagnetische straling, enzovoorts. . . Al deze interacties met de buitenwereld kunnen informatie prijsgeven over de interne toestand van het cryptosysteem: er is als het ware een extra communicatiekanaal waarover, onbedoeld, geheime informatie weglekt. Een aanvaller die fysieke toegang heeft tot de machine waarop de cryptografische bewerking wordt uitgevoerd, kan deze side channel analyseren, en een pogingen om met behulp van die informatie de sleutel te achterhalen noemt men een side channel attack. Deze nieuwe manier van kijken blijkt in veel gevallen bijzonder effectief. Veel gangbare algoritmen zijn weliswaar goed bestand tegen een puur wiskundige aanval, maar bij het ontwerp ervan is helemaal geen rekening gehouden met de mogelijkheden van side channel analyse. Zo kan bijvoorbeeld een differentiële stroomanalyse op DES, beschreven in paragraaf 6.3, al met een paar honderd cijferteksten worden uitgevoerd, zonder klareteksten. De beste niet-side-channel-aanval op DES daarentegen heeft bijna 64 terabyte aan cijfertekst en klaretekst nodig die met één enkele sleutel versleuteld zijn [Sch98]. 6.1.2

Implementatie aanvallen

Side channel attacks maken deel uit van de bredere klasse van implementatie aanvallen. Een side channel attack is een passieve aanval, wat wil zeggen dat het cryptosysteem wordt geobserveerd zonder zijn werking te verstoren. Het is ook mogelijk dat een aanvaller actief probeert het cryptosysteem te ontregelen, bijvoorbeeld door de voedingsspanning te laten fluctueren of door omgevingsfactoren als temperatuur of straling te gebruiken. Zulke aanvallen noemt men foutinjectie aanvallen, en ze worden vaak in combinatie met side channel analyse gebruikt. Hoewel foutinjectie in dit hoofstuk verder niet aan de orde zal komen, moet worden opgemerkt dat deze technieken soms nog effectiever zijn dan de aanvallen die hier worden besproken. In het begin namen sommige onderzoekers een implementatie aanval niet helemaal serieus, want “dat telt eigenlijk niet”. Zo beschrijft Bruce Schneier [Sch99] hoe iemand van de NSA1 hem jaren geleden eens uitlegde hoe een bepaald cryptosysteem gebroken was. Schneier vond het maar een geniepige aanval en riep “maar dat is valsspelen!”, waarop zijn gesprekspartner hem wat verbaasd aankeek. Want, zoals Schneier zich ook realiseerde, het is niet de taak van de aanvaller om zich aan bepaalde regels of erecodes te houden. Zijn taak is het om de geheime sleutel te achterhalen, en als hij ook maar 1

National Security Agency, een Amerikaanse inlichtingendienst

6.1 Achtergrond

41

enigszins de kans krijgt om informatie uit een side channel te halen, hoe geniepig ook, dan zal hij hier dankbaar gebruik van maken! Bij het ontwerpen van cryptosystemen voor gebruik in de praktijk (in tegenstelling tot de academische wereld) zal er dus altijd met mogelijke side channels rekening gehouden moeten worden. Schneier vermoedt dat vrijwel alle operationele cryptanalyse die bij inlichtingendiensten plaatsvindt gebruik maakt van side channel informatie [KSWH00]. 6.1.3

Simpele en differenti¨ ele aanvallen

Side channel aanvallen zijn in twee categorieën in te delen: simpele en differentiële aanvallen. Bij simpele aanvallen kan er uit één enkele meting van de side channel tijdens een cryptografische berekening rechtstreeks informatie over de geheime sleutelbits worden afgeleid. Als er veel ruis is op het kanaal, dan kan het signaal versterkt worden door over meerdere metingen (met dezelfde klaretekst of cijfertekst) te middelen. Dit soort analyses kan worden toegepast als er een direct verband bestaat tussen de sleutelbits en karakteristieke delen van het signaal op de side channel, bijvoorbeeld bij implementaties waar het executiepad afhangt van de waarde van een sleutelbit. Als het moeilijk is om een rechtstreeks verband te vinden tussen de side channel meting en de geheime sleutelbits, kan een differentiële aanval worden toegepast. Hierbij wordt gekeken naar het verschil tussen side channel metingen die horen bij verschillende berichten (klaretekst of cijfertekst). De aanvaller moet dus over meerdere afgeluisterde berichten beschikken, met de bijbehorende side channel meting. Met statistische technieken kan hieruit de sleutel worden bepaald. Dit wordt in paragraaf 6.3 verder uitgelegd, en gaat in grote lijnen als volgt: Er wordt een gok gedaan voor de waarde van één of enkele sleutelbits. Vervolgens wordt, uitgaande van die gok, voor alle berichten de waarde van een bepaalde tussenliggende bit (bijvoorbeeld een bit in de voorlaatste ronde van DES) uitgerekend. Op grond van die tussenliggende bit worden de berichten in twee groepen verdeeld. Als nu de sleutelbits goed gegokt waren, dan zal de gemiddelde side channel meting van de ene groep op een aantal punten significant van die van de andere groep afwijken. Zo niet, dan zijn de gemiddelde metingen van beide groepen nagenoeg hetzelfde. Op deze manier kan snel van enkele sleutelbits de waarde worden bepaald, en door de methode te herhalen kunnen de overige sleutelbits, onafhankelijk van elkaar, worden vastgesteld. 6.1.4

Soorten Side Channels

Het is al lang bekend dat apparaten waar geheime informatie in wordt bewerkt kwetsbaar zijn voor “lekkage” van die geheimen via fysieke kanalen. Uit de tweede wereldoorlog zijn er verhalen bekend over het gebruik van geluid als een side channel. Hierbij werd het geluid van electromechanische rotormachines2 afgeluisterd en geanalyseerd. In de jaren ’60 kon de Britse inlichtingendienst volgens oud-spion Peter Wright de versleuteling van een Frans cryptosysteem breken met behulp van gegevens die onbedoeld op een transmissielijn terechtkwamen. 2

deze rotormachines werden gebruikt om bitrijen te genereren voor stroomversleuteling

42


Omstreeks dezelfde periode realiseerden overheidsdiensten, waaronder de Amerikaanse NSA, zich dat (CRT-) beeldschermen en andere computerapparatuur electromagnetische straling produceren die ook op afstand nog te meten is. Hoewel het hier niet altijd om cryptografische apparatuur gaat, bevatten zulke systemen wel vaak gevoelige of geheime informatie. Er werd een programma opgezet met codenaam TEMPEST3 om zulke emissies bij computerapparatuur af te schermen. In de open literatuur werd in 1985 voor het eerst een onderzoek gepubliceerd naar straling van computer monitoren [Eck85], door de Nederlandse PTT-onderzoeker Wim van Eck, waarin hij aantoonde dat hij “in het wild” een systeem kon afluisteren, op een paar honderd meter afstand, met voor $15 aan apparatuur plus een televisietoestel. De electromagnetische lekkage die geproduceerd wordt door gewone computerapparatuur heet sindsdien van Eck radiation. Daarnaast is er nog een anekdote – waarvan ik de oorsprong niet heb kunnen achterhalen – over een bank met een serverruimte die direct naast de gewone bezoekersruimte lag, gescheiden door een glazen wand. Eén van de cryptografische machines in de serverruimte had groene en rode status-LEDs op het voorpaneel die direct verbonden waren met de interne databus. Door gebruik te maken van een telescoop, een fotodetector en een oscilloscoop konden aanvallers geheime informatie uitlezen. In 1996 werd door Paul Kocher4 de eerste echte side channel aanval op een cryptosysteem beschreven: de timing analysis [Koc96]. Dit is een differentiële aanval waarbij variaties in de totale looptijd van een cryptografische bewerking worden gemeten voor verschillende berichten. Om de aanval te laten slagen is vrij gedetailleerde kennis over de implementatie nodig, en nauwkeurige metingen van de looptijd. Eerst dacht men dat de vereiste nauwkeurigheid aanvallen over een netwerk onmogelijk zou maken, maar in [BB05] wordt beschreven hoe binnen een paar uur een 1024-bits RSA sleutel van een openSSL webserver te achterhalen was, via een lokaal netwerk met meerdere tussenliggende routers. Een paar jaar later werd, weer door Kocher, een nieuwe side channel ontdekt: het stroomverbruik van een implementatie. In [KJJ99] wordt beschreven hoe een differential power analysis (DPA) aanval uitgevoerd kan worden. Deze techniek is veel krachtiger dan de timing analysis, en het is moeilijker om ertegen te beschermen. We zullen in paragraaf 6.3 nader ingaan op DPA. In 2000 werd door Quisquater en Samyde [QS00] een aanval beschreven met electromagnetische straling als side channel, vergelijkbaar met van Eck straling. Deze EM analysis kan ook op enige afstand uitgevoerd worden. Wanneer een processor een berekening uitvoert, lopen er steeds wisselende electrische stroompjes door delen ervan, die zorgen dat de chip plaatselijk opwarmt. Dit gaat gepaard met kleine uitzettingen en inkrimpingen van het materiaal van de chip, wat leidt tot geluidstrillingen (in de buurt van de 10 kHz) die als side channel fungeren (acoustic analysis). Als het oppervlak van de chip met een infraroodcamera kan worden bestudeerd, kan hier soms ook informatie over de berekening uit worden afgeleid, dit heet thermal imaging. Tenslotte zijn er aanvallen mogelijk die bepaalde aspecten van de processorarchitectuur gebruiken als side channel, zoals bepaalde caches die door 3

afhankelijk van wie je het vraagt is dit “Transient ElectroMagnetic Pulse Emanation STandard” of “Telecommunications Electronics Material Protected from Emanating Spurious Transmissions” 4 Paul Kocher was ook de hoofdontwerper van de “Deep Crack” DES kraker van de EFF.

6.2 Simple Branch Prediction Analysis

43

meerdere processen gedeeld worden. Een voorbeeld hiervan is de branch prediction analysis die in de volgende paragraaf wordt beschreven.

6.2

Simple Branch Prediction Analysis

De architectuur van moderne CPU’s maakt het mogelijk een cryptografische aanval te doen die Simple Branch Prediction Analysis wordt genoemd [AKS06a, ASK06]. Voordat we beschrijven hoe de aanval in zijn werk gaat zullen we een overzicht geven van de belangrijkste hardware-elementen die hierbij een rol spelen. 6.2.1

Processorarchitectuur

Processoren maken tegenwoordig gebruik van een instructiepijplijn om de prestaties te verhogen, zodat er elke klokcyclus meerdere instructies tegelijkertijd opgehaald, gedecodeerd en uitgevoerd kunnen worden. In het ideale geval zorgt dit ervoor dat er minder dan één klokcyclus per uitgevoerde instructie nodig is. Het is echter van groot belang dat de pijplijn goed gevuld blijft met instructies, en men ontdekte al snel dat branch instructies, waarbij de executie naar een ander deel van het programma springt, de efficiëntie van de pijplijn ernstig verstoren. Bij een conditional branch, die gebruikt wordt voor if-then-else statements of while lussen, hangt het gekozen executiepad af van een bepaalde conditie. Tijdens het evalueren van die conditie zal de processor niet stilzitten, maar zal hij de instructies uit een van de twee mogelijke executiepaden “speculatief” gaan uitvoeren. Als dit achteraf het verkeerde pad blijkt te zijn geweest, dan moet de hele instructiepijplijn leeggemaakt worden en moet er opnieuw begonnen worden in het andere pad, wat relatief erg tijdrovend is. Het is dus belangrijk om voor iedere conditional branch zo goed mogelijk het gekozen executiepad te voorspellen, en dit wordt gedaan door de Branch Prediction Unit (BPU). Om de instructies na een conditional branch speculatief uit te voeren, moet de processor niet alleen weten wat de meest waarschijnlijke uitkomst van de conditie is, maar ook wat de branch target, het doel adres, van de branch instructie is. Ook deze informatie is niet altijd voorhanden. Een branch prediction unit bestaat dan ook uit twee delen: enerzijds is er de predictor, die op basis van de executiehistorie en de waarden in de registers een voorspelling doet over het te kiezen executiepad, en anderzijds de Branch Target Buffer (BTB), een cache-geheugen dat de doel adressen bevat van een aantal eerder uitgevoerde branches. Het is deze Branch Target Buffer die de side channel vormt die bij deze aanval wordt benut. Een andere techniek die in moderne processoren wordt toegepast is het gebruik van hardware-assisted multithreading. Voorheen werd multithreading op één enkele processor bereikt door de beschikbare rekentijd in korte intervallen te verdelen, en dan steeds van thread te wisselen, zodat de threads quasi-parallel worden uitgevoerd. In nieuwere CPU’s, zoals de Intel Pentium 4, worden bepaalde “goedkope” delen van de processor, bijvoorbeeld de rekeneenheden, dubbel uitgevoerd. Hierdoor ontstaan er als het ware twee logische processoren, die twee aparte processen echt parallel kunnen uitvoeren:

44


S := M for i from k − 2 to 0 do S := S ∗ S (mod N ) if di = 1 then S := S ∗ M (mod N )

Algoritme 6.1: “Square-and-Multiply” Modulaire Exponentiatie

multithreading met directe ondersteuning van de hardware. De “kostbare” onderdelen van de processor, zoals de branch prediction unit, zitten echter maar één keer op de chip en moeten door beide logische processoren worden gedeeld. Hierbij kan er via de BTB informatie van het ene naar het andere proces lekken. 6.2.2

De aanval

Hoe is deze BTB nu uit te buiten als side channel bij een aanval? We beschouwen een cryptografisch proces dat draait op een hardware-assisted multithreaded CPU. Oscar, de aanvaller, wil de geheime sleutel uit dit proces achterhalen. We nemen aan dat Oscar een eigen spy proces kan uitvoeren op dezelfde CPU, tegelijkertijd met het crypto proces. Dit is bijvoorbeeld het geval bij een multi-user webserver, of een terminal server. Het spy proces heeft geen bijzondere privileges; het kan dus niet direct het geheugen van het crypto proces uitlezen, maar, zoals we zullen zien, het kan wel de side channel uitlezen. De aanval is alleen mogelijk als het crypto proces een algoritme uitvoert dat key dependent branching doet. Dit betekent dat het executiepad afhangt van de waarden van de sleutelbits. Als voorbeeld nemen we een RSA decryptie: S = M d (mod N ), met M de cijfertekst, S de klaretekst, d = dk−1 · · · d0 de geheime sleutel, en N de publieke modulus. Om deze modulaire exponentiatie uit te rekenen wordt de Square-and-Multiply techniek gebruikt, weergegeven in algoritme 6.1. De “Multiply” stap van het algoritme (vermenigvuldiging met M ) wordt alleen uitgevoerd als de betreffende sleutelbit 1 is, en dat vormt hier de key dependent branch. Het spy proces dat Oscar parallel aan het crypto proces uitvoert om de side channel uit te lezen is eenvoudig. Het voert direct na elkaar een aantal conditional branch instructies uit (met een conditie die waar is, zodat de branch genomen wordt), en het meet de totale looptijd van al die instructies. Het aantal uit te voeren branch instructies is gelijk aan de grootte van de BTB; deze grootte is met eenvoudige benchmarks te bepalen (en mag volgens Kerckhoffs’ principe bekend worden verondersteld). De meting van de looptijd van de branch instructies wordt steeds herhaald: het spy proces doet aan het begin van iedere rekenstap van het crypto proces (het kwadrateren en het vermenigvuldigen uit algoritme 6.1) één zo’n meting.5 Als het spy proces vóór het crypto proces wordt opgestart, dan zal de BTB geheel gevuld zijn met doel adressen van het spy proces. Vervolgens begint het crypto proces 5

dit wordt beschreven in [ASK06], maar er wordt niet uitgelegd hoe het spy proces precies gesynchroniseerd wordt met het crypto proces

6.2 Simple Branch Prediction Analysis

45

Figuur 6.2: Detail van een SBPA trace

met de modulaire exponentiatie, en als het bij de conditional branch aankomt, dan zal de branch prediction unit het doel adres van die branch niet in de BTB kunnen vinden. De BPU heeft dan geen andere keus dan te voorspellen dat de branch “niet genomen” wordt. Stel nu dat de huidige sleutelbit di = 1, zodat na evaluatie van de conditie blijkt dat de branch toch wel genomen moet worden. Dan treedt er een misprediction op: de instructiepijplijn wordt leeggemaakt, het doel adres van de branch wordt in de BTB opgeslagen, en de executie gaat verder vanaf dat adres. Om plaats te maken voor dit nieuwe adres van het crypto proces moet echter een van de adressen van het spy proces uit de BTB verwijderd worden. Als het spy proces bij de volgende stap weer al zijn branch instructies uitvoert, zal er ook bij de spy een misprediction optreden, vanwege het zojuist verwijderde adres. Het spy proces meet hierdoor een langere looptijd, waaruit het kan afleiden dat het crypto proces de BTB heeft veranderd. Wanneer daarentegen de huidige sleutelbit di = 0 dan zal er geen misprediction in het crypto proces optreden. De BTB blijft dan ongewijzigd, en in het spy proces treedt ook geen misprediction op, en het meet dus geen langere looptijd. Door de looptijd van zijn eigen branch instructies te meten kan het spy proces dus een misprediction in het crypto proces detecteren. Voor elke rekenstap van het crypto proces kan uit zo’n meting worden bepaald of die stap een “Squaring” (S) of een “Multiplication” (M) was. Figuur 6.2 toont een gedeelte van de grafiek waarin de looptijd van de spy branches bij elke stap van het crypto proces is weergegeven. Zo’n trace laat duidelijk het tijdsverschil tussen de S en M stappen zien. Uit dit gedeelte van de trace kunnen de sleutelbits “. . . 011111010 . . .” worden afgeleid. Hoewel het spy proces bij elke rekenstap een tijdmeting doet, moet deze aanval niet verward worden met een timing attack. De looptijd van het crypto proces wordt hier namelijk niet gemeten; de tijdmeting is slechts een middel om de BTB te analyseren. Bovendien is een timing attack een differentiële aanval, die gebruik maakt van statistische verschillen tussen grote groepen cijferteksten. Een voordeel van deze Simple Branch Prediction Analysis is dat één side channel meting meteen al sleutelinformatie oplevert.

46


Figuur 6.3: SBPA trace van een 512-bits RSA operatie

6.2.3

Resultaten

Hoewel er verschillende factoren zijn die ruis veroorzaken bij de BTB als side channel zijn de auteurs van [AKS06a] er in de praktijk in geslaagd om tijdens één enkele trace een groot aantal sleutelbits te achterhalen. In hun artikel werd een simple branch prediction analysis beschreven op een RSA sleutel van 512 bits. Om de storende invloed van achtergrondprocessen tegen te gaan werd deze meting een aantal malen herhaald met dezelfde sleutel, op uiteenlopende tijdstippen. Hieruit is, vermoedelijk handmatig, de “duidelijkste” meting uitgekozen als eindresultaat, weergegeven in figuur 6.3. De verticale as geeft de looptijd van de spy branches aan, in processorcycli, en de horizontale as de rekenstappen van het crypto proces. Omdat van een willekeurige 512 bits sleutel ongeveer de helft van de bits “1” is zijn dit ongeveer 768 rekenstappen. De datapunten zijn gekleurd om aan te geven of de betreffende rekenstap een Squaring of een Multiplication was. Het is duidelijk dat de looptijd van de spy branches een uitstekende voorspellende waarde heeft voor het soort rekenstap (S of M), en daarmee voor de sleutelbits. Bij deze ene meting zijn er volgens de auteurs maar liefst 508 van de 512 sleutelbits rechtstreeks uit de trace af te lezen. Er zijn zes uitschieters (S stappen die ver boven de gemiddelde M stap liggen) zichtbaar in de trace; vermoedelijk kunnen twee hiervan worden uitgesloten op grond van het feit dat er geen twee M stappen direct na elkaar kunnen voorkomen.6 Deze resultaten tonen aan dat de BTB als side channel meer dan alleen een theoretisch risico vormt. Bij alle systemen waar een cryptografisch proces op dezelfde multithreaded CPU draait als processen van derden zal men hiermee rekening moeten houden. 6

maar hierover wordt in [AKS06a] niets gezegd

6.3 Differential Power Analysis

47

Figuur 6.4: SPA trace van twee DES rondes

6.3

Differential Power Analysis

Het stroomverbruik van een cryptosysteem vormt ook een side channel. De bijbehorende aanval kan niet uitsluitend met behulp van software worden uitgevoerd, maar als de aanvaller directe toegang heeft tot het cryptosysteem, dan is het stroomverbruik met eenvoudige apparatuur te meten. We zullen hier de Differential Power Analysis [KJJ98, KJJ99] beschrijven. In tegenstelling tot de eerder behandelde SBPA is dit een differentiële aanval, waarvoor meerdere berichten met bijbehorende side channel metingen verzameld moeten worden. 6.3.1

Stroomverbruik als side channel

Vrijwel alle cryptosystemen zijn tegenwoordig gebaseerd op conventionele halfgeleidertechnologie. Op het allerlaagste niveau bestaat de implementatie van een cryptosysteem dus altijd uit een netwerk van transistoren op een chip. Bij verandering van de gatespanning van een van de transistoren zal er een stroom gaan lopen door die transistor en door de verbindingen naar andere transistoren. Hierbij wordt een bepaald vermogen gedissipeerd, en wordt er elektromagnetische straling geproduceerd. Deze effecten zijn ook buiten de chip te detecteren; met name het stroomverbruik is gemakkelijk te meten. Het stroomverbruik is niet constant tijdens het uitvoeren van een cryptografische bewerking, maar hangt af van de uitgevoerde processor instructies. Een aanval die rechtstreeks uit het stroomverbruik informatie over de geheime sleutel probeert te achterhalen heet een Simple Power Analysis (SPA). Hierbij analyseert men een trace van het stroomverbruik tegen de tijd, zoals in figuur 6.4, die de tweede en derde ronde van een DES encryptie laat zien. Bij lage tijdresolutie is de structuur van een algoritme in grote lijnen zichtbaar (b.v. de zestien rondes van DES). Als het aantal meetpunten per tijdseenheid wordt verhoogd kan bijvoorbeeld het verschil tussen de “S” en “M” rekenstappen van RSA zichtbaar worden gemaakt; soms zijn zelfs de afzonderlijke processor instructies te onderscheiden. Alle algoritmen met een sleutelafhankelijk executiepad zijn, zonder tegenmaatregelen, kwetsbaar voor SPA. Wel is het zo dat het interpreteren van een trace gedetailleerde kennis vergt van de interne werking van het cryptosysteem. Hoewel de grootste stroomfluctuaties worden veroorzaakt door verschillende processor instructies, wordt het stroomverbruik ook be¨ınvloed door de datawaardes die het systeem bewerkt. Zulke data-afhankelijke effecten zijn veel kleiner, en worden vaak

48


Figuur 6.5: Schema van de laatste ronde van een DES encryptie

overschaduwd door ruis. Toch is het met statistische technieken mogelijk om informatie over de bewerkte data uit het stroomverbruik af te leiden: dit heet een Differential Power Analysis (DPA). Hierbij zoekt men naar een correlatie tussen de trace van het stroomverbruik en bepaalde bitwaarden die tijdens de cryptografische operatie worden uitgerekend. 6.3.2

De aanval

Bij een Differential Power Analysis is er weer sprake van een cryptosysteem waaruit de aanvaller Oscar de geheime sleutel wil ontfutselen. Oscar heeft toegang tot het cryptosysteem en kan het stroomverbruik ervan meten terwijl het een cryptografische bewerking uitvoert. Om de beschrijving wat concreter te maken zullen we uitgaan van een apparaat dat DES encrypties uitvoert, maar de hier beschreven techniek is in principe op alle symmetrische en asymmetrische algoritmen toepasbaar. We nemen aan dat Oscar beschikt over m cijferteksten Cm en de bijbehorende stroom-traces Im (t). Klareteksten zijn voor deze aanval niet nodig. Ook gaan we ervan uit dat Oscar niet in staat is een Simple Power Analysis te doen: hij weet ofwel niet genoeg details van de implementatie om de sleutelbits rechtstreeks uit één trace te kunnen afleiden, ofwel de stroommeting is te onnauwkeurig door ruis. Bij DES encryptie wordt de klaretekst in zestien rondes versleuteld volgens een zogenoemd Feistel-netwerk. In figuur 6.5 is schematisch de laatste van deze zestien rondes weergegeven. Het resultaat van de vorige ronde wordt in twee helften gedeeld (L15 en R15 ), en R15 wordt samen met de iteratiesleutel K16 verwerkt tot een bitrij, volgens de F -functie. Deze bitrij wordt met L15 geXORd om de nieuwe rechterhelft R16 te vormen. Voor de nieuwe linkerhelft L16 wordt R15 ongewijzigd overgenomen. Tenslotte worden de helften nog verwisseld (dit gebeurt alleen aan het eind van de zestiende ronde, niet bij de overige rondes).


49

De F -functie die de rechterhelft van de data met de iteratiesleutel vermengt tot een bitrij vormt het hart van de DES iteratie. De werking van deze functie wordt uitgebreid beschreven in hoofdstuk 2 van [Tel06]. Hier is het vooral van belang om te weten dat iedere bit van de door F geproduceerde bitrij afkomstig is uit precies één zogenoemde S-box, en dat elke S-box aangestuurd wordt door zes bits van de iteratiesleutel (en zes bits van de rechter datahelft). Als we dus de rechter datahelft kennen, en we kiezen één van de bits van de geproduceerde bitrij uit, dan zijn er precies zes sleutelbits nodig om de waarde van die bit vast te leggen. Het centrale idee achter een DPA aanval is dat Oscar herhaaldelijk een aantal van de sleutelbits gokt, en dan met behulp van de cijfertekst/stroomverbruik paren (Cm , Im (t)) controleert of die gok goed is. Oscar kiest steeds de waardes van zes sleutelbits die samen één S-box aansturen als zijn sleutelhypothese Ks . Hij zal gemiddeld ongeveer 32 sleutelhypothesen moeten testen om de juiste waarde van de zes sleutelbits te vinden. De grote kracht van de methode schuilt erin dat de sleutelhypothesen voor afzonderlijke sleutelbits onafhankelijk van elkaar te testen zijn. Om 48 van de 56 sleutelbits (corresponderend met de iteratiesleutel van de laatste DES ronde) te vinden hoeft Oscar dus maar ongeveer 8 · 32 = 256 sleutelhypothesen te testen. De resterende acht sleutelbits kunnen gemakkelijk met brutekracht gevonden worden.7 Hoe kan Oscar nu met behulp van de cijferteksten en stroomtraces controleren of een sleutelhypothese klopt? Daartoe richten we onze aandacht op een “tussenliggende bit” van het algoritme, dat wil zeggen een bit die op een bepaald moment tijdens de encryptie wordt uitgerekend. Om precies te zijn kijken we naar één bit van het resultaat van de voorlaatste DES ronde: de b-de bit van L15 , met 0 ≤ b < 32. We noemen deze bit de target bit. Gegeven een sleutelhypothese Ks kunnen we voor iedere cijfertekst C terugrekenen wat de waarde van deze bit geweest is. De functie die de waarde van de target bit “voorspelt” noemen we de DPA selectiefunctie: D(C, b, Ks ). Deze functie is vrij eenvoudig te berekenen: uitgaande van figuur 6.5 zien we dat L17 en R17 direct volgen uit de cijfertekst,8 en daarmee ook R15 en R16 . Bereken nu de b-de bit van de uitvoer van de F -functie, waarbij de corresponderende S-box aangestuurd wordt door de sleutelbits Ks . De target bit wordt verkregen door de b-de bit van de uitvoer van F te XORen met de b-de bit van R16 . Als de sleutelhypothese Ks klopt, dan zal de selectiefunctie altijd overeenkomen met de daadwerkelijke waarde van de target bit tijdens de encryptie. Met andere woorden: D(C, b, Ks ) voorspelt dan de target bit met kans p = 1. Als de sleutelhypothese Ks echter fout is, dan zal de selectiefunctie maar in ongeveer de helft van de gevallen gelijk zijn aan de daadwerkelijke waarde van de target bit: D(C, b, Ks ) voorspelt de target bit met kans p ≈ 21 . De waarde van de target bit wordt tijdens de DES encryptie in registers opgeslagen en door rekeneenheden bewerkt (b.v. bij de XOR operatie). Dit heeft een kleine, maar niet te verwaarlozen invloed op het totale stroomverbruik van het cryptosysteem. Op tijdstippen dat de target bit gemanipuleerd wordt is het stroomverbruik gecorreleerd met de waarde van die bit. Het probleem is dat het vrijwel onmogelijk is om de punten waarop deze correlatie bestaat te herkennen in de trace – dat zou in feite neerkomen op 7 8

of door de beschreven techniek aan te passen zodat naar de voorlaatste DES ronde wordt gekeken alleen moet nog de inverse van de initiële permutatie op de cijfertekst worden toegepast

50


een SPA aanval op het cryptosysteem. Gelukkig is het mogelijk om deze punten, waarop de manipulatie van de target bit het stroomverbruik be¨ınvloedt, met behulp van statistische analyse uit de trace te isoleren. Daartoe wordt de verzameling cijferteksten {Cm } in twee deelverzamelingen C0 en C1 gepartitioneerd, op basis van de DPA selectiefunctie. Voor elke deelverzameling wordt de gemiddelde stroom-trace berekend, respectievelijk I0 (t) en I1 (t). We hebben gezien dat als de sleutelhypothese klopt, dat de selectiefunctie dan altijd de goede waarde van de target bit voorspelt: in C0 zitten alle cijferteksten waarvan de target bit ook daadwerkelijk 0 is, en in C1 die waarvan de target bit 1 is. De traces I0 (t) en I1 (t) zijn in dat geval elk het gemiddelde van traces met dezelfde waarde van de target bit, dus ze zijn zelf ook gecorreleerd met die waarde. Op de tijdstippen waar de stroom gecorreleerd is aan de bitwaarde zullen I0 (t) en I1 (t) significant van elkaar verschillen. Als daarentegen de sleutelhypothese niet klopt, dan voorspelt de selectiefunctie in de helft van de gevallen de verkeerde waarde voor de target bit. De partitionering is dan een random partitionering: in elke deelverzameling zitten ongeveer evenveel cijferteksten met target bitwaarde 0 en 1. De gemiddelde traces die hieruit berekend worden, zijn dan zelf niet meer gecorreleerd met de waarde van de target bit. Er is geen significant verschil tussen I0 (t) en I1 (t), alleen wat statistische ruis, die zwakker wordt naar mate het aantal traces waarover gemiddeld wordt toeneemt. Hiermee hebben we een zeer effectieve manier gevonden om de sleutelhypothese te toetsen: we partitioneren alle cijferteksten met de selectiefunctie, berekenen de gemiddelde traces I0 (t) en I1 (t), en bepalen de differentiële trace: ∆D (t) = I0 (t) − I1 (t). Alleen als de sleutelhypothese klopt zal de differentiële trace een aantal scherpe pieken vertonen, precies op die punten waar de target bit gemanipuleerd werd. Als de differentiële trace alleen uit “witte ruis” bestaat zonder noemenswaardige pieken, dan was het selectiecriterium waarmee de cijferteksten gepartitioneerd werden niet goed, en dus klopt de sleutelhypothese niet. 6.3.3

Resultaten

In hun artikel over DPA beschrijven Kocher, Jaffe en Jun [KJJ99] een aantal succesvolle aanvallen op smartcards. Hun resultaten zijn weergegeven in figuur 6.6. De linker grafiek, figuur 6.6(a), is gemaakt bij een smartcard die DES encrypties uitvoert op bekende klareteksten. Voor deze analyse zijn 1000 berichten met bijbehorende stroomtraces verzameld (m = 103 ). De bovenste curve is een referentie trace van het gemiddelde stroomverbruik voor alle berichten; dit ligt rond de 5 mA. De onderste drie traces zijn differentiële traces ∆D (t), gemaakt met verschillende sleutelhypotheses Ks . Merk op dat de amplitude van de differentiële traces twee ordegroottes kleiner is dan die van de gemiddelde stroomtrace; de schaal is hier in µA. Het is meteen duidelijk dat de bovenste van deze drie traces gemaakt is met de juiste sleutelhypothese Ks . Rond de 75 µs is er een geprononceerde piek in ∆D (t): kennelijk werd op dit tijdstip de target bit gemanipuleerd.9 De onderste twee differentiële traces bestaan alleen uit ruis met een amplitude van ongeveer 5 µA. Hier is geen correlatie 9

omdat hier sprake is van een known plaintext attack en niet een ciphertext only attack zit de target bit juist in een van de eerste DES rondes. Voor de rest gaat de analyse precies als in paragraaf 6.3.2.


(a)

51

(b)

Figuur 6.6: DPA traces van DES encrypties op smartcards

meer tussen de voorspelde waarde van de target bit en het stroomverbruik, waaruit we kunnen concluderen dat de sleutelhypothese Ks fout was. Figuur 6.6(b) is gemaakt met een hogere tijdresolutie, waardoor de afzonderlijke klokcycli zichtbaar zijn. De bovenste trace is weer een referentie trace van het gemiddelde stroomverbruik. Omdat de amplitude ongeveer twee keer zo groot is als die van figuur 6.6(a) gaat het hier vermoedelijk om een ander model smartcard. In de middelste trace is de standaarddeviatie weergegeven van de stroommetingen, die tussen de 100 en 300 µA ligt. De interpretatie van de auteurs is dat de piek in de standaarddeviatie bij de zesde klokcyclus duidt op een grote invloed van de operand van de betreffende instructie op het stroomverbruik, en op een grote variatie in de operandwaarden. De onderste trace in de rechter grafiek is de differentiële trace ∆D (t) die ditmaal is gemaakt met m = 104 berichten, en met de juiste waarde van de sleutelhypothese Ks . Er is, met name bij de zesde klokcyclus, een sterke correlatie zichtbaar tussen het stroomverbruik en de waarde van de target bit. Op deze tijdstippen komt het signaal van ∆D (t) meer dan een orde van grootte boven het achtergrondniveau uit. Bij dit aantal berichten zijn er vrijwel geen fouten of ruis meer in de differentiële trace te zien. Kocher, Jaffe en Jun concluderen dat bijna alle cryptosystemen kwetsbaar zijn voor een DPA aanval. Zij hebben uit ongeveer 50 verschillende producten geheime sleutelinformatie weten te achterhalen, en ze beweren dat ten tijde van hun publicaties over DPA geen enkel commercieel product ertegen bestand was. Bovendien zijn DPA aanvallen betrekkelijk makkelijk uit te voeren. Er is weinig informatie nodig over de interne werking van het cryptosysteem, want de differentiële trace isoleert vanzelf de tijdstippen waar het stroomverbruik gecorreleerd is aan de target bit. Differential Power Analysis is dus een zeer krachtige techniek, waar iedereen die een cryptosysteem ontwerpt rekening mee moet houden.

52


Samenvatting en conclusies Het centrale idee van side channel analyse is dat een cryptosysteem niet beschouwd moet worden als een pure wiskundige functie, maar als een fysieke implementatie daarvan. Bij de berekening van een cryptografisch algoritme zijn er allerlei side channels, zoals stroomverbruik, tijdsverschillen en gedeelde processorcaches. Door informatie uit een side channel te gebruiken kunnen cryptosystemen veel efficiënter worden aangevallen; met name differentiële aanvallen zoals DPA zijn erg krachtig. Vermoedelijk wordt bij cryptanalyse in de praktijk bijna altijd gebruik gemaakt van side channel technieken. Meestal vereist side channel analyse fysieke toegang tot het apparaat, maar voor bijvoorbeeld de timing analysis hoeven alleen berichten van een netwerk te worden afgeluisterd, en aanvallen zoals SBPA kunnen softwarematig worden uitgevoerd op multi-user servers of terminal servers. Veel van het oorspronkelijke onderzoek op dit gebied werd gedaan met smartcards, waar de toegang tot het systeem heel eenvoudig is. Een terrein waar side channel analyse de komende tijd een belangrijke rol zal gaan spelen is dat van de Digital Rights Management (DRM)10 . Zulke systemen zijn nu nog geheel in software uitgevoerd, maar onder invloed van de entertainmentindustrie is een aantal grote spelers op de markt bezig de PC om te vormen tot een Trusted Computing Platform [TCG]. Een PC zal dan cryptografische geheimen bevatten die zijn eigenaar niet mag weten. Het zal interessant zijn om te zien of deze geheimen bestand zijn tegen verveelde tieners met kennis van side channel analyse. . . Tegenmaatregelen om cryptosystemen te beveiligen tegen side channel attacks bieden voldoende stof voor een hoofdstuk op zich. Vaak gaat het om een combinatie van technieken, waarbij enerzijds het signaal op de side channel wordt afgeschermd om het zo zwak mogelijk te maken, en anderzijds bewust ruis wordt toegevoegd aan de side channel. Uiteindelijk blijkt het echter erg moeilijk om lekkage van informatie over side channels geheel uit te bannen. Er is dus nog veel onderzoek nodig naar nieuwe cryptografische algoritmen, waarbij van meet af aan rekening wordt gehouden met het bestaan van side channels.

10

dit eufemisme wordt – terecht – ook wel omgedoopt tot Digital Restrictions Management

Hoofdstuk 7 Hellman Voorbij Door Max Waaijers

Hellman introduceerde zijn cubic-rootaanval in 1980. Sindsdien zijn er veel soortelijke Time/Memory tradeoff aanvallen voorgesteld. In dit hoofdstuk zullen enkele van dit soort aanvallen besproken worden. Allereerst zal in sectie 7.1 gekeken worden naar Time/Memory tradeoff aanvallen op blokversleutelingen. Daarna zal dit uitgebreid worden naar Time/Memory/Data tradeoff aanvallen in sectie 7.2. Vervolgens wordt in sectie 7.3 gekeken naar een Time/Memory/Key tradeoff aanval op UNIX wachtwoorden. Tot slot zal de ondergrens van dit type algoritmen besproken worden in sectie 7.4.

7.1

Time/Memory tradeoff aanvallen

Bij een T/M tradeoff aanval wordt gekeken naar het vinden van de inverse van een random functie f (x), waarbij x een sleutel is en f een one-way functie. Zowel x als f (x) bevinden zich in dezelfde zoekruimte N (wanneer dit in de praktijk niet het geval is kan gebruik gemaakt worden van een reductiefunctie R). De functie f kan gezien worden als de encryptie van een vaste klare tekst met sleutel x. Er wordt onderscheid gemaakt tussen twee fasen: een precomputatie fase en de daadwerkelijke aanval. Tijdens de precomputatie fase worden één of meerdere grote matrices aangemaakt. Het aanmaken van deze matrices kost doorgaans erg veel tijd, maar dit kan parallel gedaan worden en hoeft slechts één maal te gebeuren. De matrices worden gebruikt om de daadwerkelijke aanval te versnellen. Dit resulteert in een tradeoff tussen de hoeveelheid geheugen M die gebruikt wordt en de verwachte tijd dat een aanval kost T . Het doel van een dergelijke aanval is dus om het grootste gedeelte van de berekeningen van te voren te maken, zodat de sleutel tijdens de aanval zeer snel achterhaald kan worden. Hierdoor kan een sleutel gevonden worden voordat deze is vervangen door een nieuwe. Een verklaring van alle gebruikte parameters is te zien in tabel 7.1. 53

54

Hellman Voorbij

N P T M D

Grootte van de zoekruimte Tijd nodig voor de precomputatie fase Tijd nodig voor de daadwerkelijke aanval Hoeveelheid geheugen Hoeveelheid data beschikbaar tijdens aanval

m t

Aantal rijen van een matrix Aantal kolommen van een matrix Tabel 7.1: Gebruikte parameters

7.1.1

Hellman op blokversleutelingen

Bij een blokversleuteling wordt een klare tekst versleuteld door deze op te delen in blokken van een bepaalde grootte en elk blok afzonderlijk met een sleutel te versleutelen. In 1980 ontwierp Hellman een generieke T/M tradeoff aanval op dergelijke blokversleuteling systemen. Deze aanval zal hier besproken worden. Tijdens de precomputatie fase wordt er een matrix met m rijen aangemaakt. Het beginpunt van elke rij is een random punt in N . Door het herhaaldelijk toepassen van de functie f op de vorige waarde wordt een random pad door de zoekruimte afgelegd. Zoals in figuur 7.2 te zien is bestaat een rij uit t toepassingen van f . Van deze matrix wordt alleen de eerste en de laatste kolom opgeslagen. Het is wenselijk om met de matrix een zo groot mogelijk gedeelte van de zoekruimte te bestrijken. Echter wanneer de matrix groot wordt zullen punten er meerdere keren in gaan voorkomen. Het is zelfs zo dat wanneer twee verschillende rijen ergens een punt gemeenschappelijk hebben, deze rijen vanaf dat punt samen vallen. Door gebruik te maken van de verjaardagsstelling kan berekend worden hoe groot m en t mogen zijn:

Figuur 7.2: Hellmans matrix

7.1 Time/Memory tradeoff aanvallen

55

Figuur 7.3: Oechslins rainbow matrix

Theorem 7.1 Verjaardagsstelling: twee sets S, T ⊆ N hebben met grote waarschijnlijkheid een intersectie wanneer |S| · |T | > |N | Stel dat de eerste m rijen met t kolommen uit allemaal unieke punten bestaan. Vervolgens wordt er een nieuwe rij met k punten toegevoegd. Volgens 7.1 is het waarschijnlijk dat er een intersectie optreed wanneer (m · t) · t > N . Dus zolang mt2 ≤ N is het waarschijnlijk dat al deze punten uniek zijn. Aangezien het loont om een matrix zo groot mogelijk te maken luidt de Matrix Stopping Rule als volgt: Definition 7.2 Matrix Stopping Rule: mt2 = N Een matrix bevat hoogstens mt unieke punten, waarmee dus hoogstens 1/t deel van N bestreken wordt. De oplossing van Hellman voor dit probleem is het aanmaken van t matrices, elk met een variant fi van f , waarbij fi (x) = hi (f (x)). De functie hi kan bestaan uit het nemen van een permutatie van de bits van f (x). Tijdens de daadwerkelijke aanval moet de sleutel x bepaald worden vanuit de cijfertekst y 0 . Hiervoor wordt de functie fi weer t maal toegepast, eerst op y 0 en vervolgens steeds op het resultaat. Na elke toepassing wordt gekeken of de waarde y voorkomt in de rechter kolom. Als dat het geval is wordt vanaf het bijbehorende startpunt herhaaldelijk fi toegepast totdat y weer gevonden is. De vorige waarde is een mogelijke sleutel, welke wordt getest op een stuk cijfertekst. Dit hele proces wordt herhaald voor alle t matrices. Tijdens de daadwerkelijke aanval wordt t maal in t verschillende matrices gezocht of een waarde voorkomt. Dit resulteert in een tijd van de daadwerkelijke aanval van T = t2 . Aangezien er t matrices van lengte m en breedte 2 worden opgeslagen is de hoeveelheid geheugen dat gebruikt wordt M = tm. Samen met 7.2 resulteert dit in de volgende tradeoff voor de aanval: T M 2 = t4 m2 = N 2 (met 1 ≤ T ≤ N ) 7.1.2

Oechslins rainbow matrices

Oechslin bedacht in 2003 een andere manier om matrices te vullen. Zoals in figuur 7.3 te zien is wordt per kolom een variant fi van de functie f toegepast. Hierdoor

56

Hellman Voorbij

vallen rijen minder snel samen. Bij een Hellmans matrix vallen twee rijen samen vanaf een gemeenschappelijke waarde, bij een Oechslins matrix moeten deze waarden tevens in dezelfde kolom voorkomen voordat de rijen samenvallen. Oechslin heeft berekend dat een dergelijke matrix evenveel van de zoekruimte bedekt als t Hellmans matrices. Hierdoor kan worden volstaan met slechts één matrix tegenover t Hellmans matrices. Om te kijken of de waarde op kolom i een mogelijke sleutel is wordt de waarde ft (ft−1 (...(fi+1 (fi (x))))) berekend. Dit geeft voor de tijd van de daadwerkelijke aanval: P 2 T = ti=1 (t − i) ≈ t2 Ondanks dat het zoeken in een Oechslins matrix minder snel gaat is zoeken in een dergelijke matrix twee maal zo snel (in het slechtste geval) als bij Hellmans methode aangezien er nu volstaan kan worden met één matrix in plaats van t. 7.1.3

Distinguished points

In de praktijk wordt de daadwerkelijke tijd die nodig is voor een aanval sterk beperkt door het aantal harde schijf operaties. Een operatie waarbij data van een harde schijf gehaald wordt kost ongeveer 8 milliseconden, tegenover enkele nanoseconden voor een CPU operatie. In een Hellmans matrix moet tijdens de daadwerkelijke aanval na elke toepassing van f gekeken worden of de resulterende y in de rechter kolom voorkomt. Hiermee is het benodigde aantal harde schijf operaties gelijk aan t2 . Om het aantal harde schijf operaties tijdens een T/M tradeoff aanval te beperken stelde Rivest in 1982 voor om gebruik te maken van speciale waarden, zogenoemde ‘distinguished points’. Deze distinguished points beginnen met k nulbits. Het idee van Rivest was om door te gaan met het genereren van een rij totdat een distinguished point wordt tegengekomen. Hierdoor wordt dus een matrix verkregen met rijen van verschillende lengte. Door k te kiezen als k = log(t) is de kans op een distinguished point 1 gelijk aan 2log(t) = 1t waardoor de verwachte lengte van een rij gelijk is aan t. Tijdens de daadwerkelijke aanval hoeft nu niet na elke toepassing van f gekeken te worden of de resulterende y in de rechter kolom voorkomt, maar alleen als een distinguished point wordt bereikt. Er moet in t matrices gekeken worden of de resulterende y in de rechter kolom voorkomt, waarmee het aantal harde schijf operaties gedaald is naar t.

7.2

Time/Memory/Data tradeoff aanvallen

Bij stroomversleuteling wordt gebruik gemaakt van een generator, welke aan de hand van een sleutel een pseudo-random bitrij genereert. Deze bitrij wordt vervolgens geXORed met de klare tekst om zo de cijfertekst te krijgen. Bij een T/M tradeoff aanval op een stroomversleuteling wordt gezocht naar de interne toestand van een generator (het aantal mogelijke toestanden hoeft dus niet gelijk te zijn aan het aantal mogelijke sleutels). Bij een aanval op een blokversleuteling is de aangemaakte matrix specifiek voor een bepaalde klare tekst en kan geen gebruik gemaakt worden van het beschikbaar zijn van meerdere sleutel-cijfertekst paren om het zoeken

7.2 Time/Memory/Data tradeoff aanvallen

57

te versnellen. Bij een aanval op stroomversleuteling kan echter wel gebruik gemaakt worden van het beschikbaar zijn van meer data tijdens de daadwerkelijke aanval om deze te versnellen. De functie waarvan de inverse gezocht wordt heeft als invoer de interne toestand van de generator en als uitvoer een bitrij welke geproduceerd wordt vanaf die toestand. Aangezien voor verschillende bitrijen steeds gezocht wordt naar de inverse van dezelfde functie kan gebruik gemaakt worden van het beschikbaar zijn van meerdere bitrijen tijdens de aanval. Hiermee is de tradeoff uitgebreid naar een Time/Memory/Data tradeoff. De data die beschikbaar wordt verondersteld tijdens de daadwerkelijke aanval zijn de eerste D bits geproduceerd door de generator. Het doel van de aanval is om de interne toestand van de generator te vinden gedurende deze eerste D bits. Als deze toestand gevonden is kan de generator gebruikt worden om de rest van de bitrij te genereren waarmee de klare tekst geXORed is. Pas als de sleutel verandert moet opnieuw een aanval gedaan worden. In 1995 kwam men op het idee om Time/Memory tradeoff aanvallen uit te breiden naar Time/Memory/Data tradeoff aanvallen op stroomversleutelingen. Hieronder zullen twee verschillende algoritmen besproken worden. 7.2.1

Babbages en Golics aanval op stroomversleuteling

Babbage en Golic introduceerde in 1995 een T/M/D tradeoff aanval op stroomversleutelingen. Zij gingen uit van de functie y = f (x) waarbij x de interne toestand van de generator is en f de eerste log(N ) bits geproduceerd door de generator vanuit die toestand. Gedurende de precomputatie fase worden M willekeurige toestanden xi gekozen en de bijbehorende yi berekend. Deze tuples (xi , yi ) worden opgeslagen in een matrix (dit is dus een gedegenereerde Hellmans matrix waarbij t gelijk is aan één). Tijdens de daadwerkelijke aanval wordt gekeken naar de eerste D + log(N ) − 1 bits. Voor elke bitrij van D opeenvolgende bits wordt gekeken of deze in de matrix als yi voorkomt. Wanneer dat het geval is is de bijbehorende xi een mogelijke toestand van de generator. Op deze manier wordt voor D bitrijen gekeken of ze voorkomen in de matrix. Vanwege 7.1 moet gelden dat M D = N om met grote kans een interne toestand te vinden. De hoeveelheid tijd voor de precomputatie fase is gelijk aan de grootte van de op te bouwen matrix (P = M ). Tijdens de aanval wordt voor D bitrijen gekeken of deze in de matrix voorkomen, waardoor geldt dat T = D. Samen met M D = N geeft dit als tradeoff: T M = N . Door tijdens de daadwerkelijke aanval geen gebruikt te maken van alle D beschikbare bitrijen maar slechts van enkele wordt de begrenzing van T : 1 ≤ T ≤ D. 7.2.2

Biryukovs en Shamirs aanval op stroomversleuteling

In 2000 beschreven Biryukov en Shamir [BS00] een T/M/D tradeoff aanval op stroomversleutelingen welke gebaseerd is op Hellmans aanval op blokversleutelingen (zie 7.1.1). Biryukov en Shamir gebruiken ook t matrices van m bij t, elk met een variant fi van f . Aangezien er nu D bitrijen beschikbaar zijn tijdens de aanval hoeft er een kleiner gedeelte van de zoekruimte bestreken te worden. Het aantal matrices kan verlaagd wor-

58

Hellman Voorbij

Figuur 7.4: Genereren van een hash-waarde van een wachtwoord

den van t naar t/D (met t ≥ D). Tijdens de daadwerkelijke aanval hoeft in D minder matrices gezocht te worden, echter moet nu wel voor D bitrijen gekeken worden of ze in een matrix voorkomen. De tijd voor de aanval blijft dus: T = t2 . Het geheugengebruik gaat wel omlaag naar M = mt/D. Samen met 7.2 geeft dit de volgende tradeoff: T M 2 D2 = t2 · (m2 t2 /D2 ) · D2 = m2 t4 = N 2 (met D2 ≤ T ≤ N ) De ondergrens van D2 op T maakt dat het voordeel van het beschikbaar zijn van meer data beperkt is. Door gebruik te maken van het feit dat bij veel stroomversleutelingen het mogelijk is om alle toestanden te vinden welke k nulbits genereren kan deze ondergrens verder verlaagd worden. Definition 7.3 Sampling Resistance: R = 2−k voor een maximale k waarvoor het mogelijk is alle toestanden te vinden waaruit de generator k nulbits genereert Door alleen te kijken naar de bitrijen die beginnen met k nulbits wordt de zoekruimte verkleint naar N R = 2n−k punten. Aangenomen wordt dat de beschikbare data minstens één bitrij beginnend met k nulbits bevat (DR ≥ 1). De hoeveelheid data waarmee in de matrices gezocht wordt gaat dus omlaag naar DR. De factor R2 valt weg uit T M 2 (DR)2 = (N R)2 waardoor de tradeoff hetzelfde blijft: T M 2 D2 = N 2 . Echter de ondergrens van T is verlaagd naar (DR)2 . Verder is het aantal harde schijf operaties verlaagd van t naar tR.

7.3

T/M/K aanval op UNIX wachtwoorden

Op oudere UNIX systemen werd onderstaand algoritme gebruikt voor het produceren van een hashwaarde van het wachtwoord van gebruikers. Deze hashwaarden werden samen met de gebruikersnaam in het bestand /etc/passwd opgeslagen. Men was zo

7.4 Ondergrens

59

overtuigd van de veiligheid van het algoritme dat iedere gebruiker leesrechten voor dit bestand had. Het wachtwoord van de gebruiker werd ingekort tot 8 karakters. Door elk karakter met 7 bits te representeren werd zo een sleutel van 56 bits verkregen. Deze sleutel werd gebruikt om een nulstring van 64 bits te encoderen met DES. De resulterende cijfertekst werd weer geëncodeerd met DES. Dit werd 25 keer herhaald, waarbij tevens gebruik gemaakt werd van een 12 bits ‘salt’ waarde welke een extra permutatie na elke ronde definieerde. De na 25 ronden verkregen cijfertekst werd samen met de waarde van het salt opgeslagen in base64 formaat. Aangezien dit systeem gebruik maakt van blokversleuteling is een Time/Memory/Data tradeoff aanval zoals in 7.2 beschreven niet mogelijk. Wel is het mogelijk om gebruik te maken van meerdere cijfertekst-sleutel paren aangezien steeds dezelfde klare tekst wordt geëncodeerd. Dit is dus een Time/Memory/Key tradeoff aanval, wat een variant is op T/M/D tradeoff aanvallen en beschreven wordt in [ABS05]. Verondersteld wordt dat het bestand met wachtwoorden van een redelijk groot bedrijf met 1024 werknemers is bemachtigd (Dk = 210 ). De grootte van de zoekruimte is: N = 256 · 212 = 268 bits. De hoeveelheid tijd die nodig is voor de precomputatie fase is P = DNk = 258 . Verondersteld wordt voor het geheugengebruik dat 512 GB beschikbaar is. Dit geeft M = 236 (8 byte waarden). Met de in 7.2.2 gevonden T/M/D tradeoff van T M 2 Dk2 = N 2 resulteert dit in een tijd voor de daadwerkelijke aanval van: T = 244 evaluaties, wat in ongeveer een uur gedaan kan worden op een super computer. Dit algoritme wordt momenteel weinig meer gebruikt. Tegenwoordig wordt een variant van MD5 vaak gebuikt als hashfunctie (dit is te zien aan de opgeslagen hashwaarde: deze begint in dat geval met $1$). Verder wordt er op veel systemen gebruik gemaakt van zogenaamde ‘shadow passwords’, waarbij de hashwaarden in een apart bestand worden opgeslagen dat alleen voor super-users leesbaar is.

7.4

Ondergrens

Barkan, Biham en Shamir hebben in [EBS06] een ondergrens voor T/M respectievelijk T/M/D tradeoff aanvallen bewezen. Hiertoe voeren ze een verborgen toestand s in. Deze verborgen toestand is in veel algoritmen impliciet aanwezig. Zo is het het matrix nummer bij Hellmans matrices en het kolomnummer bij een Oechslins matrix. Door invoering van deze verborgen toestand neemt de zoekruimte toe van N naar N S, waarbij S de verzameling van mogelijke waarden van s is. De random graaf bij T/M tradeoff aanvallen is nu een stateful-random graaf; het pseudo-random gedrag van f wordt be¨ınvloed door s. De functie h definieert de transitie van de ene knoop in de graaf naar de andere knoop: (yi , si ) → (yi+1 , si+1 ) met yi+1 = f (yi ) en si , si+1 de waarden van de verborgen toestand gedurende yi en yi+1 . Door het expliciet maken van deze verborgen toestand wordt bewezen dat het aantal verschillende p waarden van y welke met M rijen bestreken kan worden van boven begrensd is door 2 SN M ln(SN ). Om minimaal de helft van de zoekruimte te bestrijken moet gelden dat:

60

Hellman Voorbij N 2

p p ≤ 2 SN M ln(SN ) ≤ 2 SN M ln(N 2 )

Hieruit kan een ondergrens voor het aantal verborgen toestanden berekend worden: S≥

N 32M lnN

Barkan, Biham en Shamir nemen aan dat h minimaal ts maal wordt toegepast voor elke verborgen toestand s (zolang de waarde nog niet gevonden is in de matrix), waarbij ts de grootste afstand is van een willekeurig punt in de matrix met verborgen toestand s naar het bijbehorende eindpunt in de matrix. Onder deze aanname bewijzen ze de volgende ondergrens voor de looptijd van de daadwerkelijke aanval: 2

T = Ω( M 2Nln(N ) ) Voor een T/M/D tradeoff aantal geldt een ondergrens van: 2

T = Ω( M 2 DN2 ln(N ) ) Als dit vergeleken wordt met de in 7.1.1 en 7.2.2 gevonden looptijden is te zien dat in beide gevallen nog slechts een kleine winst van ln(N ) te behalen is.

Samenvatting en conclusies Bij een Time/Memory tradeoff aanval wordt gekeken naar het vinden van de inverse van een random functie f (x), waarbij x een sleutel is en f een one-way functie. Door een groot gedeelte van de berekeningen van te voren te doen en de resultaten op te slaan in matrices gaat de daadwerkelijke aanval erg snel. Een probleem is dat erg grote matrices de zoekruimte niet efficiënt bestrijken. Hellman loste dit probleem op door het invoeren van meerdere matrices, elk met een variant fi van f . Oechslins oplossing voor dit probleem was het gebruiken van een verschillende functies fi per kolom. Het zoeken in deze matrices gaat een factor 2 sneller vergeleken met t Hellmans matrices. In 1982 stelde Rivest zogenaamde distinguished points voor om het aantal harde schijf operaties te verminderen en zo de zoektijd in de praktijk sterk terug te brengen. Bij een aanval op een stroomversleuteling wordt er gezocht naar de interne toestand van de generator. Er kan gebruik gemaakt worden van het tijdens de aanval beschikbaar zijn van meer data, waardoor een Time/Memory/Data tradeoff ontstaat. De gebruikte methode lijkt erg op die van Hellman, maar vanwege het beschikbaar zijn van meer data zijn minder matrices nodig. Door gebruik te maken van de sampling resistance van een generator kan de ondergrens op de aanvalstijd verlaagd worden. Barkan, Biham en Shamir hebben in 2006 ondergrenzen voor Time/Memory respectievelijk Time/Memory/Data tradeoff aanvallen bewezen. De gevonden ondergrenzen zijn slechts een factor ln(N ) beter dan de in dit hoofdstuk besproken methoden.

Hoofdstuk 8 UPnPTM Door Paul Bouman

UPnPTM staat voor ”Universal Plug and Play”. Het UPnPTM forum, dat verantwoordelijke is voor de ontwikkeling en het beheer van de techniek, bestaat momenteel (Februari 2007) uit 811 leden. De eerste versie van de UPnPTM Device Architecture, het document waarin de technologie beschreven wordt, is uitgebracht op 08 Juni 2000. Als we de naam ”Universal Plug and Play”bekijken bestaat het grootste deel van deze titel uit ”Plug and Play”, een term die vooral populair is gemaakt door Microsoft bij de lancering van Windows 95. Met ”Plug and Play”werd het mogelijk allerlei randapparatuur aan te sluiten, zonder dat er van alles handmatig geconfigureerd moest worden of er nog een keer met de hand drivers ge¨ınstalleerd moesten worden. UPnPTM trekt dit principe verder: het gaat nu niet meer om insteekkaarten, muizen, harde schijven of andere hardware die direct aan één computer aangesloten moet worden, maar het geheel moet over een netwerk gaan werken. In dit hoofdstuk zal ik eerst uitleggen met welke doelstelling UPnPTM ontworpen is. Vervolgens zal ik dit ontwerp uitleggen en daarna zal ik de cryptografische aspecten van UPnPTM toelichten. Tot slot zal ik het gebruik van UPnPTM in de praktijk schetsen en ook enkele bezwaren noemen en laten zien hoe UPnPTM gebruikt kan worden bij aanvallen op de digitale veiligheid.

8.1

Doelstelling van UPnPTM

Volgens de website van het UPnPTM -Forum zelf is de doelstelling van UPnPTM : ”The goals of the Forum are to allow devices to connect seamlessly and to simplify the implementation of networks in the home and corporate environments. The Forum will achieve this by defining and publishing UPnPTM device Control protocols built upon open, Internet-based communication standards.-[Forc]

61

UPnPTM

62

Kader 8.1: IP met Postduiven Bij wijze van 1 april werd in 1990 RFC1149 geschreven. Dit rfc beschrijft een protocol voor IP over luchttransport, CPIP (Carrier Pigeon Internet Protocol) [blua]. Uiteindelijk werd de eerste implementatie getest en gebruikt op 28 april 2001. Er werd in Noorwegen een pingsessie uitgevoerd met postduiven. Omdat het goed weer was duurde het wat langer voor de duiven op hun bestemming aankwamen, en de OCR software die gebruikt moest worden om de briefjes in te scannen bleek niet goed om te kunnen gaan met de letter F, maar nadat deze problemen handmatig gecorrigeerd waren, verscheen uiteindelijk het bericht 64 bytes from 10.0.3.1: icmpseq=0 ttl=255 time=6165731.1 ms [blub] op het scherm. Simpeler gezegd komt dit erop neer dat men de verbindingsmogelijkheden van randapparatuur wil verbeteren en vereenvoudigen door gebruik te maken van netwerktechnologie en webstandaarden. Het interessante is dat de enige eis die aan het netwerk wordt gelegd is dat het TCP/IP ondersteunt. Dit maakt de keus aan verbindingen enorm: Ethernet, Wifi, Firewire, Seriële en Parallelle kabels, USB, Token Ring en zelfs de ouderwetse postduif [8.1]. Door het gebruikt van internettechnologie zijn apparaten in het geheel onafhankelijk van het onderliggende hardware platform. Een printer die vroeger alleen met een windows machine zou communiceren, zou als UPnPTM -printer opdrachten van alle besturingssystemen die UPnPTM -printers ondersteunen kunnen afdrukken. Toch is de gebruikersinterface waarmee de apparatuur bediend kan worden nog steeds in handen van de fabrikanten. Apparatuur wordt namelijk met het HTTP protocol bediend, wat inhoudt dat de gebruiker mooie HTML in de browser te zien krijgt. De diversiteit van mogelijk gebruikersinterfaces is dus even groot als de diversiteit aan mogelijke webpagina’s. Toch kunnen apparaten ook op een generieke manier bediend worden, door Remote Procedure Call (RPC) via SOAP (wat gebaseerd is op XML) toe te laten.

8.2

Ontwerp van UPnPTM

Zoals in de technische beschrijving [Forb] van UPnPTM wordt beschreven, bestaat het uit een aantal fasen, namelijk: • Addressing • Discovery • Description • Control • Eventing • Presentation

8.2 Ontwerp van UPnPTM

63

Figuur 8.2: Discovery fase schema

Hierbij moet opgemerkt worden dat de Addressing fase eigenlijk geen onderdeel is van het UPnPTM -protocol dat de apparaten op een netwerk met elkaar voeren. De Discovery en Description fases vinden na elkaar plaats, terwijl Control, Eventing en Presentation naast elkaar plaats vinden. 8.2.1

TM Rollen in UPnP

In UPnPTM kent men twee rollen: het UPnPTM Device en het UPnPTM Control Point. Een UPnPTM Device kan meerdere UPnPTM Services in zich hebben en kan ook weer UPnPTM subdevices in zich hebben (die op hun beurt ook weer services en subdevices in zich kunnen hebben). UPnPTM Devices leveren in feite diensten: een printer kan de dienst ”printen”leveren, een scanner de dienst ”scannenën een multifunctionele printer/scanner/copier kan zowel een printer als een scanner subdevice hebben. Het

UPnPTM

64

Figuur 8.3: Description fase schema

UPnPTM Control Point is in feite de gebruiker van deze diensten. Dat kan een stuk software zijn dat bijvoorbeeld elke minuut een beeld van een webcam apparaat op wil vragen, of gewoon een gebruiker die met de browser van de presentatie dienst van een apparaat gebruikt maakt. 8.2.2

Addressing

Het doel van de Addressing fase is een IP adres te verkrijgen. In veel grote netwerken ligt het voor de hand dat er een DHCP server draait die alle computers een IP adres toewijzen. Dat is ook wat UPnPTM in eerste instantie doet: broadcast een DHCP request en wacht op een antwoord. In een LAN zal dit wel werken, maar als het gebruikte netwerk bijvoorbeeld over ’e’en USB kabel van de computer naar het apparaat loopt, is het een stuk minder waarschijnlijk dat hier een DHCP request beantwoord zal worden. Omdat de doelstelling van UPnPTM dusdanig geformuleerd is dat er in dit geval ook geen configuratie plaats zou moeten vinden, is er ook een oplossing voor deze situatie. In RFC 3927 [Gro] worden de zogenaamde Link-Local adressen beschreven. Een apparaat dat aan een netwerk toegevoegd wordt en geen adres krijgt, gokt een adres in de daarvoor bestemde 169.254/16 range. Vervolgens wordt getest of dit adres vrij is en indien dat niet zo is, wordt er een nieuw adres gegokt totdat een vrij adres gevonden wordt. Omdat het netwerk met deze techniek verdeeld zou kunnen raken in twee netwerken op het moment dat de DHCP server tijdelijk uitvalt, is het noodzakelijk dat apparaten met een 169.254/16 adres regelmatig proberen of er niet ineens een DHCP server op het netwerk is gekomen. 8.2.3

Discovery

In de Discovery fase gaat erom dat apparaten elkaar ontdekken. Een UPnPTM device dat aan het netwerk wordt toegevoegd wil zichzelf kenbaar maken aan de rest. Een

8.2 Ontwerp van UPnPTM

65

Kader 8.4: Simple Object Access Protocol In het Simple Object Access Protocol is het mogelijk om methodes of commando’s uit te voeren over het netwerk. Op wikipedia is bijvoorbeeld een SOAP transmissie te vinden die er als volgt uitziet: Request:

Reply:

In een programmeertaal zou deze berichtenuitwisselingen het gevolg kunnen zijn van een statement als ProductDetails details = warehouse.getProductDetails(827635); UPnPTM Control Point dat aan het netwerk wordt toegevoegd, wil weten wat er voor apparaten beschikbaar zijn in het netwerk. De Discovery fase zorgt hiervoor met behulp van het Simple Service Discovery Protocol [Fora] of kortweg SSDP protocol. Als een UPnPTM Device aan het netwerk wordt toegevoegd, broadcast deze Discovery pakketjes naar het netwerk. In deze pakketjes staat wat basale informatie, zoals het adres van het apparaat en welk apparaat het is. Een UPnPTM Control Point dat op het netwerk komt broadcast een search request. Hierin staat het adres van het apparaat. Als reactie hierop zullen UPnPTM devices die zo’n bericht ontvangen, een bericht naar het Control Point sturen met daarin weer informatie over zichzelf. Als dit alles heen en weer gestuurd is, weten de Control Points in het netwerk als het goed is welke apparaten zich allemaal op het netwerk bevinden waar ze deze kunnen vinden. 8.2.4

Description

Na de Discovery fase weet het Control Point wellicht welke apparaten er allemaal in het netwerk zitten, maar het weet nog niet wat deze apparaten allemaal kunnen of doen. Voordat een Control Point echter van apparaten gebruik gaat kunnen maken, is het natuurlijk wel handig als het Control Point weet wat deze apparaten kunnen. Hiervoor wordt de Description fase uitgevoerd. In de Description fase stuurt het Control Point een bericht naar de apparaten waar het meer van wil weten. De apparaten reageren dan

UPnPTM

66

met een device Description, waarin de fysieke en logische structuur van het apparaat wordt beschreven. Hier staat dus in welke services en subdevices het apparaat allemaal in zich heeft. Ook kan een apparaat een service Description sturen naar het Control Point. Hierin staat een lijstje met uitvoerbare commando’s (bij een printer kun je je bijvoorbeeld voorstellen dat er een ”print”commando te vinden zal zijn) en de beschikbare variabelen van deze service. Hieraan kan bijvoorbeeld gedacht worden aan een temperatuursensor in een UPnPTM -koelkast, die een variabele ’temperatuur’ aanpast in het geval de temperatuur verandert. Deze omschrijvingen gebeuren allemaal in XML en hoe een dergelijke omschrijving er in XML uit zou moeten zien, is allemaal terug te lezen in het ”Universal Plug and Play Device Architecture”document. 8.2.5

Control

In de Control fase gaat het Control Point daadwerkelijk gebruik maken van de diensten van de UPnPTM devices. Het Control Point weet nu immers welke diensten er op het netwerk aanwezig zijn, waar deze diensten aanwezig zijn en welke commando’s er naartoe gestuurd kunnen worden. Het Control Point kan deze acties uitvoeren door berichten volgens de SOAP-standaard versturen. SOAP [Wik] staat voor ”Simple Object Access Protocolën is wederom een vorm van XML en wordt door het W3C beheerd. In het kader [8.4] wordt een voorbeeld van een SOAP berichtenuitwisselingen gegeven. In de praktijk zal dus een Control Point een SOAP bericht ”print”naar een printer kunnen sturen met een document in de XML, waarna de printer dit document zal gaan printen. Ook is het in de Control fase mogelijk dat de waarde van een variabele van een service wordt opgevraagd. In het gevoel van de koelkast kan een stuk software dat op het Control Point draait dus aan de koelkast zijn temperatuur opvragen. 8.2.6

Eventing

In de Eventing fase gaat het vooral om de variabelen van de services. Een Control Point dat ge¨ınteresseerd is in een gebeurtenis, kan aan een subscription request sturen naar die service, zodat hij geabonneerd wordt op die gebeurtenis. Hierop stuurt het apparaat een akkoord terug met daarin de duur van het abbonnement. Het is de zaak van het Control Point om voordat deze tijd verstreken is, indien hij nog ge¨ınteresseerd is in de gebeurtenissen, zijn abonnement te verlengen. In het geval de gebeurtenis waarop het Control Point geabonneerd is plaatsvindt, zal nu het UPnPTM device naar alle geabonneerde Control Points een bericht opsturen waarin staat dat de gebeurtenis plaatsvond en wat daarbij de relevante gegevens waren. Een voor de hand liggend voorbeeld van een gebeurtenis die plaats kan vinden, is het veranderen van een variabele. Voor een schematische weergave van deze fase, zie [8.6]. 8.2.7

Presentation

De presentatie fase komt neer op een gebruiker die met de webrowser de webinterface van het UPnPTM device bezotk. Het UPnPTM device stuurt een website in de Hypertext

8.3 Cryptografie in UPnPTM

67

Figuur 8.5: Control fase schema

Markup Language, of HTML [Con] terug, wat een grafische presentatie in het scherm van de gebruiker oplevert.

8.3

Cryptografie in UPnPTM 8.3.1

Security Ceremonies

In de vorige sectie is het hele principe van UPnPTM beschreven, maar hier kwam geen encryptie in voor. Dit is ook niet gek, want de basisarchitectuur van UPnPTM legt helemaal geen verplichting op tot het gebruik van cryptografische technieken. Eigenlijk is het zelfs zo dat de verschillende apparaten op een netwerk elkaar blind vertrouwen. Nu snapten de makers van UPnPTM ook wel dat dit misschien niet de meest ideale situatie is. Daarom heeft men bij Intel een Security Model ontwikkeld dat op UPnPTM kan lopen en daarmee Identificatie, Authenticatie, Autorisatie, Integriteit, Versheid en Geheimhouding toevoegt aan de uitwisseling van Control/SOAP berichten. Belangrijk bij dit beveiligingsmodel is het zogenaamde begrip Security Ceremonies [Ell]. Tijdens het ontwerpen van dit model bedacht men bij Intel namelijk dat de beveiliging van een systeem namelijk altijd afhankelijk is van menselijk handelen. Een computer kan namelijk nooit weten hoe zijn eigenaar vindt dat de beveiliging ge-

UPnPTM

68

Figuur 8.6: Event fase schema

regeld moet zijn in het systeem, als de eigenaar deze informatie zelf niet in het systeem stopt. Ook zaken als gebruiksrechten zijn nooit door een computer te bepalen: deze zullen door een beheerder ingevoerd moeten worden. Vanuit deze gewaarwording beredeneerde Intel dat het niet genoeg is een beschrijving te maken van een beveiligingsprotocol, maar dat het voor het ontwerpen van een beveiligd systeem nodig is een deze beschrijving uit te breiden met de interactie van de mens. Security Ceremonies zijn dus een ontwerp van een beveiligingssysteem waarin de interactie van de gebruiker ook expliciet vermeld wordt. In het beveiligingsmodel voor UPnPTM bestaan de gegevens die de gebruiker moet leveren aan het systeem uit: • Informatie over eigenaren en gebruikers (wie beheert welk apparaat?) • Regels voor het gebruik van apparaten (welke gebruiker mag wat doen op welk apparaat?) • Certificaten (wat zijn de publieke sleutels van de apparaten in het netwerk?)

8.3 Cryptografie in UPnPTM

69

Kader 8.7: De Discovery fase beveiligd Door een SecurityConsole te gebruiken kan de Discovery fase beveiligd worden uitgevoerd. De groene stippellijntjes geven aan dat de gebruiker fysiek informatie van het apparaat moet halen, door bijvoorbeeld een label te lezen. Rode lijntjes geven een gebruikersinterface op de computer aan en de zwarte lijntjes stellen normale netwerkcommunicatie voor. De gebruiker leest het SecurityID van het apparaat. De SecurityConsole ondekt het beveiligde apparaat via het normale SSDP. Elke keer dat de Security Console een apparaat tegenkomt dat de service DeviceSecurity kent, vraagt het de public keys van dit apparaat op. De SecurityConsole gebruikt nu de publieke keys van de apparaten om de SecurityID’s van de apparaten te berekenen en laat deze zien aan de gebruiker. De gebruiker vergelijkt deze SecurityID’s met de ID die hij eerder heeft opgehaald en mag het apparaat een naam geven, waarna het Discovery proces voltooid is. Hierop volgend gaat de gebruiker over rechten en eigendom onderhandelen met het beveiligde apparaat. 8.3.2

DeviceSecurity en de Security Console

In de wereld van UPnPTM Security bestaat er een Device genaamd Security Console. Ook bestaat er een service met de naam DeviceSecurity. Elk apparaat dat aan beveiliging wil doen, zal de service DeviceSecurity aan moeten bieden. Bij het Discovery proces kan dit apparaat er gewoon voor kiezen op de reguliere manier mee te doen. In dat geval zien andere apparaten de DeviceSecurity service op het apparaat en weten dat het apparaat aan beveiliging doen. Het reguliere SSDP is echter niet beveiligd. Er bestaat ook een Security Ceremony waarin het Discovery proces wel beveiligd kan verlopen. Dit staat weergegeven in kader [8.7]. De Service DeviceSecurity heeft nu 5 acties die uitgevoerd kunnen worden, te weten: • TakeOwnership • ListOwners • GrantOwnership • RevokeOwnership • FactorySecurityReset

UPnPTM

70

Met deze acties kunnen de eigenaren van een apparaat beheerd worden. De SecurityConsole voert deze acties uit nadat een gebruiker via een gebruikersinterface een opdracht heeft gegeven ’e’en van deze acties uit te voeren. Een SecurityConsole is de eigenaar van een apparaat als het apparaat de public key van de SecurityConsole in zijn lijst met eigenaren heeft staan. Voor alle beveiligde operaties op een apparaat zijn sessies sleutels benodigd, behalve de operaties TakeOwnersip en SetSessionkeys. Het verkrijgen van een sessie key gaat als volgt: 1. De SecurityConsole vraagt de public key van het beveiligde apparaat. 2. De SecurityConsole vraagt welke cryptografische algoritmes en protocollen ondersteund worden door het beveiligde apparaat. 3. De SecurityConsole vraagt de LifeTimeSequenceBase van het beveiligde apparaat op. Naarmate de tijd verstrijkt veranderd deze waarde, waardoor versheid van public-key acties gegarandeerd kan blijven. 4. De SecurityConsole genereert sessie sleutels en stuurt deze naar het apparaat, versleuteld met de public key van dit apparaat, in een aanroep van SetSessionKeys. Nu de mogelijkheden er zijn om de eigenaren vast te stellen, kunnen die eigenaren aan de slag gaan om gebruiksrechten in te stellen waarmee het gebruik van de subdevices en andere sevices op het beveiligde apparaat geregeld kan worden. Het gaat echter wat ver om deze procedure in zijn geheel uit te leggen, maar de ge¨ınteresseerde lezer zal alles kunnen vinden in het document van Intel. 8.3.3

Beveiliging in de Control Fase

Nu de rechten en eigenaren goed zijn ingesteld, kan er daadwerkelijk op een beveiligde manier gebruik gemaakt worden van de ’reguliere’ UPnPTM apparaten. Dit betekent in feite dat de Control fase beveiligd wordt. Als het beveiligde apparaat nu een Controlopdracht binnenkrijgt, zal deze niet per direct worden uitgevoerd, maar zal deze eerst het schema uit figuur [8.8] doorlopen. Iemand die een bericht stuurt, kan geidentificeerd worden aan de hand van zijn SecurityID. Dit is de Hash van zijn Public Key. Als een SOAP bericht aankomt, wordt eerst gekeken of er een SecurityInfo element in het bericht zit. Als dit het geval is, wordt er aangenomen dat het bericht ondertekend is. Als het bericht niet ondertekend is, wordt de afzender op ”Unknown”gezet. Als het bericht wel ondertekend is, wordt de handtekening geControleerd. Als deze niet klopt, is het einde verhaal en wordt een foutmelding teruggestuurd. Als het proces doorgaat, wordt vervolgens geControleerd of de afzender wel voldoende rechten heeft om de actie uit te voeren. Als dit het geval is, wordt de actie uitgevoerd. Een speciale actie die in dit schema voorkomt, is de DAE of Decrypt and Execute actie. Dit kan gebruikt worden om een geheel SOAP-bericht te versleutelen met de public key van het apparaat. Dit versleutelde bericht wordt dan meestal in een DAE-bericht gestopt. Dit DAE-bericht zal meestal niet ondertekend worden, maar het versleutelde bericht wel. Op deze manier kan iemand die afluistert in zijn geheel niet weten welk SOAP-bericht verstuurd is naar het apparaat.

8.4 UPnPTM in de praktijk

71

Figuur 8.8: De Control Fase Beveiligen

8.4

UPnPTM in de praktijk 8.4.1

Internet Gateway Device

In de praktijk wordt UPnPTM eigenlijk vooral gebruikt in routers, waarop het zogenaamde Internet Gateway Device ge¨ımplementeerd is. Het grote voordeel hiervan is dat het het oplossen van het NAT-traversal probleem[8.9] mogelijk wordt. De Internet Gateway Device maakt het namelijk mogelijk om portforwarding regels in de gateway aan te passen door middel van SOAP-berichten. In de situatie waarin Alice en Bob nu een directe webcam verbinding willen maken met elkaar, kan Alice nu een UPnPTM berichtje naar de Gateway sturen waarmee een poort wordt opengezet, en via een externe partij (in casus [8.9] MSN.COM) Bob laten weten dat de poort open staat en wat het internet adres van gateway is. Het vervelende is echter dat het beveiligingsmodel dat in de vorige sectie behandeld is, in de praktijk eigenlijk nooit ge¨ımplementeerd is in UPnPTM apparatuur. In de realiteit vertrouwen UPnPTM apparaten op een lokaal netwerk elkaar dus eigenlijk blind, wat tot vervelende situaties kan leiden.

UPnPTM

72

Kader 8.9: Het probleem van NAT Traversal Het probleem van NAT traversal doet zich voor als twee computers beiden via een gateway, die aan Network Address Translation (NAT) doet, direct met elkaar willen communiceren. De computers achter een NAT-gateway delen namelijk allemaal hetzelfde IP adres op het internet. Het is dus erg moeilijk om een directe verbinding te maken tussen twee computers uit verschillende NATgateway-netwerken, zonder dat één van de gateways het binnenkomende verkeer op een bepaalde poort expliciet doorstuurt naar één computer in het interne netwerk (portforwarding). In het plaatje kunnen Alice en Bob wel via MSN communiceren door hun verbindingen 1 en 2 te gebruiken, omdat verbindingen naar buiten toe geen probleem zijn bij NAT. Het wordt echter wel een probleem als Alice en Bob elkaar een bestand willen sturen of de webcam willen gebruiken. MSN.com heeft ook maar beperkte bandbreedte, dus het is geen optie alle webcam transacties die op het internet plaatsvinden via hen te laten lopen. Alice en Bob willen dus eigenlijk zorgen dat ze verbinding 3 met elkaar maken, maar dat kan alleen als één van de twee op de gateway een poort laat forwarden. 8.4.2

Misbruik van het Internet Gateway Device

In April 2006 formuleerde Armijn Hemel [Hem06] in zijn paper “Universal Plug and Play: Dead simple or simply deadly?” een gevaar dat ontstaat door dit Internet Gateway device. Zoals eerder gesteld vertrouwen alle UPnPTM apparaten op een netwerk elkaar en het is juist dit vertrouwen dat door potentiële aanvallers misbruikt kan worden. In zijn paper laat Hemel zien dat iemand het voor elkaar krijgt één systeem in het netwerk een klein programmaatje uit te laten voeren, een enorme hoeveelheid aanvallen op de communicatie in het netwerk kan uitvoeren. Een aanval waar machines in het interne netwerk, die normaal afgeschermd waren van de buitenwereld, ineens direct aanspreekbaar op het internet maken, is nu mogelijk. De aanvaller kan bijvoorbeeld de fileserver bereikbaar maken en zo bij interne bestanden komen. Een andere aanval die Hemel formuleert is de het kapen van poorten. Als Oscar toegang heeft tot het netwerk van Alice en zorgt dat de gateway van Alice de webcam poort niet forward naar de interne PC van Alice, maar de computer van Oscar op het internet, zal Bob met Oscar gaan webcammen, terwijl hij denkt dat hij dat met Alice zal gaan doen. Ook wordt het mogelijk om spam “wit te wassen”, doordat Oscar zijn spam via het netwerk van Alice naar Alice haar internet provider stuurt. De internet


73

provider zal nu denken dat Alice een spammer is en haar daar op aanspreken, maar Alice weet nergens van. Er zijn nog meer aanvallen mogelijk, maar daarvoor raad ik aan het artikel zelf te lezen. 8.4.3

TM De toekomst van UPnP

UPnPTM wordt momenteel in erg veel huis tuin en keuken routers gebruikt, waardoor de aanvallen die Hemel beschrijft in veel situaties mogelijk is. Een hoop van deze huis tuin en keuken routers worden ook in het midden en klein bedrijf gebruikt, dus ook bedrijfsnetwerken kunnen gevoelig zijn voor deze aanvallen. Het gebruik van het UPnPTM Security model zou het één en ander op kunnen lossen, ware het niet dat Hemel geen routers heeft kunnen vinden die dit model ondersteunen. Zolang dat niet het geval is komt het advies van Hemel in feite neer op het volledig uitschakelen van UPnPTM op de router. De vraag is echter of fabrikanten bereid zijn het Security model van UPnPTM te gaan ondersteunen. Fabrikanten vinden het namelijk een nogal ingewikkeld systeem en het maakt het gebruik van de apparatuur UPnPTM een stuk lastiger, omdat de gebruiker nu toch aan het configureren moet slaan. En dat staat eigenlijk haaks op het “Plug and Play” principe. Een mogelijke opvolger van UPnPTM is echter ook al geformuleerd: het Devices Profile for Web Services [CCK+ ], of kortweg DPWS. In DPWS is wel een standaard security model geformuleerd en is het ook noodzakelijk dat dit gebruikt wordt als DWPS opdrachten van het ene naar het andere netwerk reizen. De opvolger van Windows XP, Windows Vista heeft ondersteuning voor DWPS, maar het is maar de vraag of fabrikanten van randapparatuur ook staan te trappelen om deze techniek te gaan gebruiken. Wat dat betreft is de strijd tussen gebruikersgemak en veiligheid nog lang niet gestreden.

Samenvatting en conclusies UPnPTM is een protocol dat gebruiksvriendelijkheid voorop stelt en daarin ook slaagt. Het ontwerp is zo gemaakt dat UPnPTM Control Points goed weten welke apparatuur op het netwerk te vinden is, zodat er direct gebruik van kan worden gemaakt. Doordat alles via SOAP en XML gaat, is het ook niet meer nodig om specifieke drivers voor apparatuur te hebben. Het Security model van UPnPTM werkt met een Public/Private key cryptografie. In het ontwerp is de interactie van de mens ook meegenomen, waardoor het idee van een Security Ceremonie ontstaat. Aangezien de mens altijd een belangrijke factor is in de veiligheid van een bepaald systeem, is dit laatste idee een interessante les voor de toekomst, die wellicht ook in andere situaties toepasbaar is. Het gebruik van UPnPTM leidt in de praktijk tot veiligheidsproblemen, zoals Hemel illustreert in zijn paper. Dit komt echter vooral voort uit het ”Plug en Play”principe en het feit dat de apparatuur op de markt het Security model van UPnPTM helemaal niet implementeert. Wellicht dat de opvolger DWPS deze problematiek zal verhelpen in

74

UPnPTM

de toekomst. Toch blijft de les dat veiligheid en gebruikersgemak vaak niet samen gaan een belangrijke om rekening mee te houden.

Hoofdstuk 9 Smashing SMASH Door Roeland Luitwieler

Hashfuncties worden veel gebruikt in de cryptografie, onder andere bij digitale handtekeningen en niet-interactieve zero-knowledge proofs. Recent gevonden botsingen voor met name de populaire hashfuncties MD4, MD5, RIPEMD, HAVAL-128, SHA-0 en SHA-1 hebben voor veel opschudding gezorgd en vormen een aanleiding om nieuwe hashfuncties te ontwerpen en te analyseren. Eén voorstel voor een nieuwe ontwerpmethode was SMASH, gepresenteerd door Lars R. Knudsen in 2005 ([Knu05]), dat in sectie 9.2 zal worden besproken. Helaas werd SMASH al snel gebroken door Pramstaller, Rechberger en Rijmen, later in 2005 ([PRR05]), wat het onderwerp zal zijn van sectie 9.3. Eerst komt in sectie 9.1 het een en ander over hashfuncties in het algemeen aan bod.

9.1

Inleiding

Een hashfunctie is een functie H : B∗ → Bn , waarbij B de verzameling van bits is, te weten {0, 1}. Er zijn drie belangrijke eisen voor een cryptografische hashfunctie H: 1. One-way. Deze eis is gericht tegen het vinden van een inverse: gegeven y = H(x), vind x moeilijk. 2. Zwak botsingsvrij. Deze eis is gericht tegen het vinden van een tweede inverse: gegeven x en y = H(x), vind x0 6= x met y = H(x0 ) moeilijk. 3. Sterk botsingsvrij. Deze eis is gericht tegen het vinden van een botsing: vind x en x0 6= x met H(x) = H(x0 ) moeilijk. Hierbij betekent moeilijk zoals gebruikelijk “met minstens evenveel werk als een brutekrachtaanval”. Een brutekrachtaanval gebruikt H als black box. Het verwachte aantal n toepassingen √ van H bij een brutekrachtaanval is 2 voor het vinden van een (tweede) inverse en 2n voor het vinden van een botsing (met een verjaardagsaanval, gebaseerd 75

76

Smashing SMASH

op de verjaardagsstelling). Verder noemen we dat een sterke botsingsvrijheid van H zwakke botsingsvrijheid van H impliceert, maar niet andersom; analoog impliceert een zwakke botsingsvrijheid van H dat H one-way is, maar niet andersom. De werking van de meeste (populaire) hashfuncties. De meeste hashfuncties gebruiken een blokfunctie h : Bn × Bl → Bn , waarmee chaining wordt toegepast. Een bericht m waarvan de hashwaarde moet worden verkregen, wordt dan in t blokken m1 , m2 , . . . , mt van l bits gehakt, waarbij het laatste blok mt wordt aangevuld met bits volgens een bepaalde botsingsvrije padding-regel, zodat ook dat blok l bits lang is; vervolgens wordt H(m) berekend op deze manier (met iv de initial value, een vaste waarde): h0 = iv hi = h(hi−1 , mi ) H(m) = ht

(1 ≤ i ≤ t)

De eisen voor de hashfunctie vertalen zich dan naar dezelfde eisen voor de blokfunctie. De blokfunctie kan natuurlijk op allerlei manieren ge¨ımplementeerd zijn, bijvoorbeeld door hem te definiëren als h(hi−1 , mi ) = Ehi−1 (mi ) ⊕ mi , waarbij Ehi−1 een blokcijfer is met sleutel hi−1 en ⊕ de XOR-operatie. Dit specifieke voorbeeld lijkt nog het meest op de manier waarop SMASH werkt, zoals we in de volgende sectie zullen zien. De notatie die hier ge¨ıntroduceerd is, zullen we in heel dit hoofdstuk blijven gebruiken.

9.2

SMASH

SMASH is een ontwerpmethode voor hashfuncties bedacht door Lars R. Knudsen in 2005 ([Knu05]). Eerst zullen we zien hoe SMASH werkt, dan bespreken we de ideeën erachter en ten slotte komen de door Knudsen gespecificeerde twee concrete instanties van SMASH aan de orde: SMASH-256 en SMASH-512. 9.2.1

De werking van SMASH

SMASH gebruikt een blokfunctie h : Bn × Bn → Bn , waarbij dus beide invoeren en de uitvoer een lengte van n bits hebben. De blokfunctie maakt gebruik van een vaste, non-lineaire, bijectieve kernfunctie f : Bn → Bn , die efficiënt te berekenen moet zijn, bijvoorbeeld door middel van een blokcijfer met een vaste sleutel. Belangrijk hierbij is dat aangenomen wordt dat f (zo goed als) random is. De hashwaarde H(m) wordt berekend op deze manier (vergelijk met de bovengenoemde vergelijkingen): h0 = f (iv) + iv hi = f (hi−1 + mi ) + hi−1 + θ · mi H(m) = f (ht ) + ht

(1 ≤ i ≤ t)

(9.1) (9.2) (9.3)

Hierbij is θ 6= {0, 1} een vast element van GF (2n ) en gebeurt het optellen en vermenigvuldigen ook in GF (2n ) (voor een opfriscursus eindige lichamen, zie kader 9.1).

9.2 SMASH

77

Kader 9.1: Eindige lichamen. Een element van het eindig lichaam of Galoislichaam (Engels: finite field, Galois field ) GF (pn ) is een polynoom van graad n − 1 met coëfficiënten in Zp . Het optellen gebeurt puntsgewijs (in Zp dus) en het vermenigvuldigen gebeurt modulo een vast, irriducible polynoom van graad n, zodat de graad van het resulterende polynoom weer kleiner dan n is. Een irriducible polynoom van graad n is een polynoom dat niet het product is van twee polynomen van graad < n. Eindige lichamen zijn met beide operaties een wiskundige groep. Een element van GF (pn ) kan worden gerepresenteerd door middel van een rij van n getallen uit Zp . Omdat we bij SMASH werken we met p = 2, is elke bitrij van n bits dus op te vatten als een element van GF (2n ). Merk op dat optellen in GF (2n ) daarmee gelijk is aan de XOR-operatie, wat dus heel efficiënt gedaan kan worden. Omdat θ in SMASH een vaste waarde heeft, kan ook vermenigvuldigen met θ efficiënt gedaan worden, mits θ goed gekozen wordt. Dit is altijd mogelijk, omdat er maar weinig beperkingen op de keuze van θ zijn. 9.2.2

Idee¨ en achter SMASH

Het voornaamste idee achter SMASH is natuurlijk dat de hashfunctie anders is opgezet dan de populaire hashfuncties, omdat die laatsten nou juist gebroken waren. Voordat we deze verschillen bespreken, behandelen we eerst de drie eigenschappen die vereist zijn voor de kernfunctie f : 1. Non-lineair. Dat f (zo goed als) random is, moet ervoor zorgen dat f onvoorspelbaar is, zodat de verschillende bits elkaar zoveel mogelijk be¨ınvloeden (te vergelijken met symmetrische encryptie). 2. Effici¨ ent te berekenen. Dit natuurlijk opdat het berekenen van een hashwaarde ongeveer net zo snel gebeurt als bij de populaire hashfuncties, terwijl SMASH meer elementen bevat. 3. Bijectief. Deze eis is er opdat f sterk botsingsvrij is en daarmee cryptografisch sterker. Dit zorgt er wel voor dat f ook te inverteren is. Omdat f efficiënt te berekenen is, wordt ook aangenomen dat f −1 efficiënt te berekenen is. Dit betekent zelfs dat vergelijking 9.2 te inverteren is; kies gegeven hi een willekeurige a, bereken b = f −1 (hi + a) = hi−1 + mi en vind hi−1 en mi door µ ¶ 1 1 (a b) = (hi−1 mi ) θ 1 op te lossen, wat altijd mogelijk is, omdat θ 6= 1. Hiermee is h dus niet cryptografisch sterk, ja, zelfs niet one-way. Dit maakt de hashfunctie als geheel nog niet cryptografisch zwak, want zoals we verder op zullen zien, haalt SMASH zijn kracht uit andere elementen van de hashfunctie. Wel is hiermee een meet-in-themiddle-aanval mogelijk geworden (vergelijkbaar met de bekende aanval op 2-DES),

78

Smashing SMASH

√ waarmee voor het vinden van een (tweede) inverse slechts ongeveer 2n bereken ningen nodig zijn in plaats √ van 2 berekeningen. Toch maakt dit niet zoveel uit, omdat het uitvoeren van 2n berekeningen toch al ondoenbaar moest zijn tegen een verjaardagsaanval. Nu we de kernfunctie besproken hebben, kijken we naar de drie belangrijke verschillen tussen SMASH en de populaire hashfuncties: 1. Het gebruik van ´ e´ en vaste kernfunctie f in plaats van heel veel verschillende functies. Waar de blokfuncties van de populaire hashfuncties een “kernfunctie” g : Bn × Bl → Bn gebruiken, gebruikt SMASH de kernfunctie f : Bn → Bn ; je kunt g dus zien als een functie die 2l functies Bn → Bn definieert (of 2n functies Bl → Bn ), terwijl f er maar één definieert. Het idee hierachter is, dat als maar een paar functies die g definieert cryptografisch zwak zijn, de deur al open staat voor een aanval, terwijl je f zo sterk mogelijk kunt kiezen. 2. Het vermenigvuldigen met θ in (9.2). Dit moet de blokfunctie extra onvoorspelbaar maken, opdat een botsing ondoenlijk gevonden kan worden (vergelijkbaar met de kolomvermenigvuldiging bij AES), omdat een aanvaller geen controle heeft over hi−1 (vanwege de vaste waarde voor h0 ). Ook het vinden van een bruikbare (tweede) inverse met de bovengenoemde meet-in-the-middle-aanval moet hierdoor bemoeilijkt worden, omdat een aanvaller geen controle heeft over mi . Merk op dat de restrictie dat θ geen 0 of 1 mag zijn er is, omdat anders de vermenigvuldiging weg zou vallen. 3. De extra toepassingen van f . De kernfunctie f wordt bij SMASH twee keer extra toegepast ten opzichte van de ontwerpmethode van populaire hashfuncties: (a) Aan het begin, namelijk in (9.1). Deze moet in combinatie met de XORoperatie pseudo-aanvallen buiten de deur houden; van de combinatie van een (zo goed als) willekeurige afbeelding met een XOR-operatie op deze manier wordt in de cryptografie namelijk aangenomen dat die sterk botsingsvrij is. Pseudo-aanvallen verschillen van echte aanvallen in dat een willekeurige beginwaarde iv gekozen mag worden. Hier zou een aanvaller extra voordeel uit kunnen halen. De gekozen bewerking van iv moet dit ondoenbaar maken. (b) Aan het einde, namelijk in (9.3). Dit moet, weer in combinatie met de XOR-operatie, het vinden van een (tweede) inverse ondoenbaar maken; dit des te meer omdat f inverteerbaar is (zie boven). Samenvattend kunnen we zeggen dat, hoewel een cryptografisch zwakke kernfunctie f wordt gebruikt, het vermenigvuldigen met θ en de extra bewerkingen aan begin en eind SMASH cryptografisch sterk moeten maken. Differenti¨ ele cryptanalyse. De blokfunctie h heeft behalve inverteerbaarheid ten slotte nog een niet zo handige eigenschap, die naar voren komt bij een differentiële cryptanalyse ervan1 ; Knudsen definieerde deze eigenschap zelf al, namelijk forward prediction: 1

Bij differentiële cryptanalyse worden twee overeenkomstige berekeningen met elkaar vergeleken; in ons geval gaat het om het berekenen van de hashwaarde van twee verschillende berichten. De variabele

9.2 SMASH

79

kies bij willekeurige hi−1 en h∗i−1 met verschil h0i−1 de waardes mi en m∗i met verschil m0i = h0i−1 ; dan geldt: h0i = hi + h∗i = (1 + θ)h0i−1 (9.4) Dit volgt uit het uitwerken van de definities: h0i = = = = = = = = =

hi + h∗i f (hi−1 + mi ) + hi−1 + θ · mi + f (h∗i−1 + m∗i ) + h∗i−1 + θ · m∗i f (hi−1 + mi ) + f (h∗i−1 + m∗i ) + hi−1 + h∗i−1 + θ · mi + θ · m∗i f (hi−1 + mi ) + f (h∗i−1 + m∗i ) + hi−1 + h∗i−1 + θ(mi + m∗i ) f (hi−1 + mi ) + f (h∗i−1 + m∗i ) + h0i−1 + θ(h0i−1 ) f (hi−1 + mi ) + f (h∗i−1 + m∗i ) + (1 + θ)h0i−1 f (hi−1 + mi ) + f (hi−1 + h0i−1 + mi + h0i−1 ) + (1 + θ)h0i−1 f (hi−1 + mi ) + f (hi−1 + mi ) + (1 + θ)h0i−1 (1 + θ)h0i−1

Met deze keuze voor de verschillende invoeren, vallen de toepassingen van f dus tegen elkaar weg! Merk ook op dat deze eigenschap uitbreidbaar is naar een willekeurig aantal y iteraties, waarbij je telkens de berichtblokken met het juiste verschil kiest: h0i = (1 + θ)h0i−1 h0i+1 = (1 + θ)2 h0i−1 h0i+2 = (1 + θ)3 h0i−1 .. .

voor m0i = h0i−1 voor m0i+1 = h0i = (1 + θ)h0i−1 voor m0i+2 = h0i+1 = (1 + θ)2 h0i−1 .. .

h0i+y = (1 + θ)y+1 h0i−1

voor m0i+y = h0i+y−1 = (1 + θ)y h0i−1

(9.5)

Knudsen gaf aan dat deze eigenschap op zichzelf nooit tot een botsing kan leiden, omdat h0i+y 6= 0 voor willekeurige y. Daar had hij gelijk in, maar we zullen zien in sectie 9.3 dat deze eigenschap bij een aanval toch benut kan worden. 9.2.3

Twee concrete instanties van SMASH: SMASH-256 en SMASH-512

De specificatie voor SMASH-256 is als volgt: • n = 256. • GF (2256 ) wordt gedefinieerd door het irriducible polynoom q(θ): q(θ) = θ256 + θ16 + θ3 + θ + 1

(9.6)

waar θ een wortel van moet zijn. uit de tweede berekening die overeenkomt met een variabele uit de eerste, markeren we hier en in het vervolg telkens met een ster, en het verschil tussen de twee variabelen met een accent. Voorbeeld: hi heeft als overeenkomstige variabele h∗i en het verschil tussen beiden is h0i .

80

Smashing SMASH

• De kernfunctie f is als volgt opgebouwd uit drie verschillende H-rondes en een L-ronde (die we hieronder zullen behandelen): f = H1 ◦ H3 ◦ H2 ◦ L ◦ H1 ◦ H2 ◦ H3 ◦ L ◦ H2 ◦ H1 ◦ H3 ◦ L ◦ H3 ◦ H2 ◦ H1 (9.7) • iv = 0, 256 ‘0’-bits dus. • Deze paddingregel wordt gebruikt: als m het bericht is van 0 < t < 2128 bits lang (de lengte van het bericht moet dus ook aan deze restrictie voldoen), en u de oplossing van (t + 1) + u ≡ 128 mod 256; laat het bericht m dan aangevuld worden met respectievelijk één ‘1’-bit, u ‘0’-bits en de 128-bits binaire representatie van t. De specificatie voor SMASH-512 lijkt hier sterk op: • n = 512. • GF (2512 ) wordt gedefinieerd door het irriducible polynoom q(θ): q(θ) = θ512 + θ8 + θ5 + θ2 + 1

(9.8)

waar θ een wortel van moet zijn. • De kernfunctie f is als volgt opgebouwd uit drie verschillende H-rondes en een Lronde (waarbij de rondes iets zijn aangepast ten opzichte van SMASH-256, zoals we zullen zien): f = H1,3,2 ◦ L ◦ H2,3,1 ◦ L ◦ H1 , 2, 3 ◦ L ◦ H2,1,3 ◦ L ◦ H3,2,1 ◦ L ◦ H3,1,2

(9.9)

met Ha,b,c = Ha ◦ Hb ◦ Hc . • iv = 0, 512 ‘0’-bits dus. • Deze paddingregel wordt gebruikt: als m het bericht is van 0 < t < 2256 bits lang (de lengte van het bericht moet dus ook aan deze restrictie voldoen), en u de oplossing van (t + 1) + u ≡ 256 mod 512; laat het bericht m dan aangevuld worden met respectievelijk één ‘1’-bit, u ‘0’-bits en de 256-bits binaire representatie van t. De H-rondes en de L-ronde. Voor de volledigheid vermelden we de exacte opbouw van de verschillende rondes uit de kernfuncties zoals gedefinieerd in (9.7) en (9.9). SMASH-256 is ontworpen voor een 32-bits architectuur. Alle functies hebben een 256-bits in- en uitvoer. Een H-ronde is opgebouwd uit bitrotaties en het toepassen van S-boxen. Het verloop van een H-ronde is weergegeven in algoritme 9.2. De drie soorten H-rondes verschillen alleen in de gebruikte 4 × 4 bijectieve S-box; hierbij betekent Sbs(x, y, z, w) dat voor alle j = 0, . . . , 31, de vier j de bits van x, y, z, w worden geëvalueerd door de betreffende 4 × 4 bijectieve S-box (“Sbs” staat voor “S-box bit-slice”), waarbij het bit uit x doorgaat voor het meest significante. Het verloop van een L-ronde is weergegeven in algoritme 9.3. De gebruikte functies spreken verder voor zich; zo betekent RotateLeft(x, y) dat de variabele x over y p osities naar links wordt geroteerd, enzovoort. De S-boxen die SMASH-256 gebruikt zijn (H-ronde Hk gebruikt

9.2 SMASH

81

H-ronde(a): (* Laat a7 , a6 , a5 , a4 , a3 , a2 , a1 , a0 de 256 bits van a zijn, met elke aj 32 bits lang *) (a7 , a6 , a5 , a4 ) := Sbs(a7 , a6 , a5 , a4 ) for i = 0, . . . , 3 do ai+4 := ai+4 ⊕ RotateLeft(ai , ri ) (a3 , a2 , a1 , a0 ) := Sbs(a3 , a2 , a1 , a0 ) for i = 0, . . . , 3 do ai := ai ⊕ RotateLeft(ai+4 , ri+4 ) (a7 , a6 , a5 , a4 ) := Sbs(a7 , a6 , a5 , a4 ) for i = 0, . . . , 3 do ai+4 := ai+4 ⊕ RotateLeft(ai , ri+8 ) (a3 , a2 , a1 , a0 ) := Sbs(a3 , a2 , a1 , a0 ) for i = 0, . . . , 3 do ai := ai ⊕ RotateLeft(ai+4 , ri+12 )

Algoritme 9.2: Het verloop van een H-ronde in SMASH-256.

S-box Sk ): S1 S2 S3

s0 s1 s2 s3 s4 s5 s6 : 6 13 12 7 15 1 3 : 1 11 6 0 14 13 5 : 4 2 9 12 8 1 14

s7 s8 s9 10 8 11 10 12 2 7 15 5

s10 5 9 0

s11 0 7 11

s12 2 3 6

s13 4 8 10

s14 14 15 3

s15 9 4 13

Nu rest ons nog uit te leggen waar de variabelen ri uit algoritme 9.2 vandaan komen; die komen uit deze tabel van rotaties (H-ronde Hk gebruikt rotaties Rk ): R1 R2 R3

: : :

r0 r1 r2 19 18 17 22 29 12 4 21 19

r3 r4 r5 r6 r7 r8 r9 7 1 7 26 20 0 16 4 18 2 13 29 26 20 5 24 20 12 16 14 30

r10 20 16 3

r11 5 29 4

r12 28 18 23

r13 2 4 15

r14 20 10 13

r15 4 9 12

L-ronde(a): (* Laat a7 , a6 , a5 , a4 , a3 , a2 , a1 , a0 de 256 bits van a zijn, met elke aj 32 bits lang *) a3 := a3 ⊕ ShiftLeft(a7 , 8) a2 := a2 ⊕ ShiftLeft(a6 , 8) a1 := a1 ⊕ ShiftRight(a5 , 8) a0 := a0 ⊕ ShiftRight(a4 , 8)

Algoritme 9.3: Het verloop van een L-ronde in SMASH-256.

82

Smashing SMASH

SMASH-512 volgt SMASH-256 weer op de voet. SMASH-512 is ontworpen voor een 64-bits architectuur en alle functies hebben een 512-bits in- en uitvoer. De H-rondes en L-ronde zijn exact gelijk, alleen hebben alle aj uit algoritmes 9.2 en 9.3 een lengte van 64 bits in plaats van 32, en worden andere rotaties gebruikt: R1 R2 R3

: : :

r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 56 40 24 8 55 48 61 14 37 13 24 8 48 32 12 62 57 35 1 45 8 56 48 0 22 21 7 44 34 30

r10 25 33 62

r11 17 13 2

r12 61 4 58

r13 29 60 50

r14 13 12 34

r15 45 20 10

Het is bijna overbodig om te melden dat deze tabellen zo zijn ontworpen, dat het aantal bits dat elkaar be¨ınvloedt optimaal is.

9.3

Het breken van SMASH

Nog in 2005 presenteerden Norbert Pramstaller, Christian Rechberger en Vincent Rijmen een botsingsaanval op SMASH ([PRR05]), waarmee bewezen werd dat SMASH niet sterk botsingsvrij is. De aanval is gebaseerd op een uitbreiding van de forward prediction-eigenschap genoemd in (9.4). De aanval is makkelijk uit te voeren, slaagt met kans 1 en stelt slechts weinig beperkingen op de botsende berichten, zodat ook (mis)bruikbare botsingen geconstrueerd kunnen worden. Het meest ingenieuze van deze aanval is nog wel (vooral nu we net de kernfuncties van SMASH-256 en SMASH-512 tot in detail behandeld hebben) dat de gebruikte kernfunctie er niet toe doet, waarmee de hele ontwerpmethode van SMASH gebroken is; dit omdat de toepassingen van f tegen elkaar wegvallen op de manier die we al gezien hebben bij de forward predictioneigenschap. Voordat we laten we zien hoe SMASH-256 en SMASH-512 te breken zijn, kijken we eerst hoe dat in zijn werk gaat b ij een eenvoudigere instantie van SMASH. 9.3.1

Het breken van SMASH-ORDy

Merk allereerst op dat we, teneinde een botsing te verkrijgen, een strategie moeten bedenken om twee verschillende berichten zo op te stellen, dat ergens in de berekeningen het verschil h0j = 0 ontstaat; wanneer dit gelukt is en de berichtblokken mk en m∗k zijn verder voor k > j gelijk (ofwel m0k = 0), zal ook het verschil tussen de uiteindelijke hashwaardes 0 zijn, waarmee we dus een botsing gevonden hebben. Als we tussen de eerste berichtblokken een willekeurig verschil m01 = x introduceren, zal na de eerste iteratie een bepaald verschil h01 zijn ontstaan; laten we dat verschil a noemen. Wanneer we de forward prediction-eigenschap benutten zoals in (9.5), wordt dit verschil voortgeplant als h02 = (1 + θ)a na de tweede iteratie en als h0y+1 = (1 + θ)y a na de (y + 1)de iteratie. Als we nu SMASH-ORDy definiëren als een variant van SMASH waarin we θ zo mogen kiezen dat (1 + θ) orde y heeft, met andere woorden (1 + θ)y = 1 (we werken immers in een wiskundige groep), dan wordt h0y+1 = (1 + θ)y a = 1 · a = a. Om deze vergelijking op 0 te krijgen, hoeven we alleen nog maar een verschil van a

9.3 Het breken van SMASH

83

toe te voegen, want a + a = 0; maar we weten al hoe dat moet, want na de eerste iteratie hadden we dat verschil ook al verkregen! Het komt erop neer dat we ervoor moeten zorgen dat de invoeren van f in beide berekeningen in de (y + 1)de iteratie (absoluut) gelijk is aan de invoeren van f in de eerste iteratie. Omdat er voor de toepassing van f in (9.2) eerst een additie (XOR-operatie) met hi−1 plaatsvindt, moet my+1 dus gelijk zijn aan m1 plus h0 (voor de XOR-operatie in de eerste iteratie) plus hy (voor de XOR-operatie in de (y + 1)de iteratie). Voor m∗y+1 geldt een vergelijkbare redenering en omdat m01 = x, h∗0 = h0 en h∗y = hy + (1 + θ)y−1 a komen we uit op m∗y+1 = m1 + x + h0 + hy + (1 + θ)y−1 a. Al deze termen kunnen gemakkelijk van tevoren worden berekend en daarom kunnen bijvoorbeeld voor een succesvolle botsingsaanval op SMASH-ORD3 de volgende berichten worden berekend: m1 m2 m3 m4

= = = =

z1 z2 z3 z1 + h0 + h3

m∗1 m∗2 m∗3 m∗4

= = = =

z1 + x z2 + a z3 + (1 + θ)a z1 + x + h0 + h3 + (1 + θ)2 a

(9.10)

met z1 , z2 , z3 en x willekeurig, waarbij een botsing optreedt na de vierde iteratie. 9.3.2

Het breken van SMASH-256

De hierboven beschreven aanval is niet direct uit te breiden naar SMASH-256, omdat in het eindige lichaam gedefinieerd door q(0) uit (9.6) de orde van (1 + θ) gelijk is aan ((2256 − 1)/5); het aantal berichtblokken dat vereist is voor de aanval wordt dan ((2256 − 1)/5) + 1, wat meer is dan het aantal toegestane berichtblokken 2120 − 1 (dat is 2128 −1 bits gedeeld door 256). We kunnen echter de aanval zo uitbreiden dat veel minder berichtblokken nodig zijn. We gaan ervoor zorgen dat een verschil wordt opgebouwd van de vorm a · q(0), wat gelijk is aan a · 0 = 0, omdat we modulo q(0) rekenen (de a is hier weer hetzelfde gedefinieerd als boven). Hiertoe herintroduceren we het verschil a op de manier van de beschreven aanval niet slechts één keer, maar meerdere keren; door de juiste berichtblokkeuze wordt dit toegevoegde verschil weer op dezelfde manier P voortgeplant als in (9.5), zodat we elk verschil j (1 + θ)cj a wat we maar willen (met cj willekeurig) kunnen introduceren, zolang de voorraad berichtblokken strekt. Dan moet a · q(0) natuurlijk wel zo te schrijven zijn, wat gelukkig zo is, omdat (9.6) kan worden herschreven als q(θ) = θ256 + θ16 + θ3 + θ + 1 = 1 + (1 + θ)2 + (1 + θ)3 + (1 + θ)16 + (1 + θ)256 wat het gewenste resultaat oplevert: a · q(θ) = a + (1 + θ)2 a + (1 + θ)3 a + (1 + θ)16 a + (1 + θ)256 a. Om de laatste term te introduceren hebben we 257 berichtblokken nodig en voor de andere termen minder, dus de aanval vereist op zijn minst 257 berichtblokken. Bij de iteraties 1, 241, 254, 255 en 257 introduceren we nu het verschil a als in sectie 9.3.1, waardoor m241 , m254 , m255 en m257 van het eerste bericht vaststaan door de keuze van x = m01 = m1 + m∗1 ; alle andere berichtblokken van het eerste bericht mogen verder vrij

84

Smashing SMASH

gekozen worden, terwijl van het tweede bericht alleen het eerste blok vrij gekozen mag worden, waarna de andere blokken vast liggen. Het opstellen van de berichten werkt dus geheel analoog aan (9.10). 9.3.3

Het breken van SMASH-512

Ook voor SMASH-512 geldt in het eindige lichaam gedefinieerd door q(0) uit (9.8) dat de orde van (1 + θ) te groot is voor de aanval uit sectie 9.3.1, want ord(1 + θ) = 2512 − 1 en 2512 > (2256 − 1)/512. Omdat (9.8) echter herschreven kan worden als q(θ) = θ512 +θ8 +θ5 +θ2 +1 = 1+(1+θ)+(1+θ)2 +(1+θ)4 +(1+θ)5 +(1+θ)8 +(1+θ)512 kan wel weer de aanval uit de vorige sectie toegepast worden. Voor de aanval zijn deze keer 513 berichtblokken nodig, waarbij we het verschil a introduceren bij de iteraties 1, 505, 508, 509, 511, 512 en 513 op precies dezelfde manier als eerder.

Samenvatting en conclusies We hebben in dit hoofdstuk gezien wat de ontwerpmethode van SMASH inhoudt en wat de ideeën erachter zijn. Daarna zagen we in een differentiële cryptanalyse dat SMASH niet sterk botsingsvrij is, ongeacht de keuze voor de kernfunctie. Merk op dat SMASH nog wel zwak botsingsvrij is, omdat beide (en niet slechts één van beide) berichten aan bepaalde restricties moeten voldoen voordat de beschreven aanval slaagt. De beschreven aanval is zelfs praktisch toepasbaar vanwege de lage kosten, de weinige restricties op de botsende berichten en de zekerheid van slagen. Daarmee is SMASH niet alleen smashed, maar ook zwakker dan populaire hashfuncties als MD5 en SHA-1. Is SMASH dan helemaal voor niets ontworpen? Natuurlijk niet. We kunnen en moeten van SMASH leren op onze zoektocht naar sterk botsingsvrije hashfuncties.

Chapter 10 Privacy-Preserving Data Mining Written by Henno Vermeulen

This chapter is about privacy-preserving data mining: the retrieval of data mining results on data that is distributed between multiple parties, with each party revealing the least possible amount of data about individual records to the other parties. Privacy-preserving data mining is useful when the data is sensitive; in particular when a database contains records about single persons. For example medical researchers may be interested in finding associations between certain genes and diseases in patient records. One hospital could have records about the presence or absence of diseases in patients, and independent researchers could have records on the same patients, but about the presence or absence of certain genes in patients. Another example would be the approval or denial of loan or credit card applicants. Two parties are interested in making a yes/no classification tree of people who are highly probable to default on the loan on the basis of a sample database with certain attributes such as age, sex, job, income, etc. . . . An insurance company could have records on age, sex, and the class variable payment yes/no of individuals. A bank could have records with job and income of individuals. Most countries also have laws that forbid the disclosure of personally identifiable data, so that it may even be illegal to share databases for data mining. There are two ways in which the total data can be partitioned among the parties. Both the examples above are examples of horizontally partitioned data: each party has records on the same entities, but they have different attributes. Of course they should share the same identifiers for each entity. This can be for example a social security number. Data can also be vertically partitioned : each party has records with the same attributes. This can for example happen when several insurance companies have data on their own customers and together they wish to perform privacy-preservering data mining. In this paper we shall focus on the mining of association rules, specifically on data that is vertically partitioned between two parties. 85

86

Privacy-Preserving Data Mining

10.1

Data Mining

Data mining is the discovery of knowledge from data. Contrary to calculating simple statistics over a database, the purpose of data mining is to learn models from the data. Some common data mining methods are described below. It is interesting to note that the main secure protocol used in all the methods mentioned below is the calculation of the scalar product of binary vectors held by each party. We shall see how this arises in the mining of association rules, which will be discussed in section 10.3. • Bayesian Networks This is a form of graphical modelling. A Bayesian network is a graph that models dependencies and conditional probabilities between different attributes in the data. The paper by [WY04] discusses the privacy-preserving computation of Bayesian network structure in vertically partitioned data. Bayesian models can also be used for classification, where the class variable is represented by a node in the graph. • Classification Trees A classification tree is a tree for deciding, for new data, which class label will be the most probable. It is built on the basis of a sample database for which the class of each record is known. The class label can be for example payment yes/no in the case of loan applicants. Each node in the tree represents a question on an attribute value, which can be answered by yes or no. A new applicant is run down the tree by answering these questions, starting at the root node, and going to the left node when the answer is yes, and to the right node when the answer is no, until a leaf node is found. The leaf nodes contains the most probable class label. Questions can be for example “income less than 20000?”, ”age less than 30?”, “sex is male?”, etc. . . . These questions are learned from the sample data such that the tree will work well for this data. (Usually this is improved upon by pruning the tree to prevent overfitting to specific peculiarties of the training data. This can be done by splitting the sample data in a training set to build the tree, and a test set of records that is run down the tree and its pruned variants to see which performs the best.) • Association Rules Finding associations between items of transactions; this is often used to determine which items are typically bought together in one transaction. A classical example (which may be a false urban legend) is the rule found in a grocery store that beer ⇒ diapers; so people who buy beer have a higher probability of buying diapers than people who don’t buy beer.

10.2 Secure Multiparty Computation

10.2

87

Secure Multiparty Computation

Privacy-preserving data mining is a special case of secure multiparty computation: n different parties each have private data xi (e.g. a database table) and they wish to calculate a certain function (e.g. the result of a data mining method) f (x1 , x2 , . . . , xn ),

(10.1)

while party i wishes to keep its data xi unknown to the other parties. 10.2.1

The Ideal Protocol

The best possible preservation of privacy (ideal) we can get is where each party only knows its own input contribution xi and the result f . Theoretically, the ideal privacy preservation can be obtained by the presence of an external trusted party performing the calculation of f . Each party submits its value xi to the trusted party, the trusted party then evaluates f and returns the result to all parties, without revealing any intermediate results of the calculation of f . This is known as the ideal protocol . Of course in some cases sensitive data can still be inferred when using the ideal protocol. For example, two parties calculating the sum of their private numbers will know the other party’s number by simply substracting its own number from the sum. Generally this is not the case for data mining because the result of the calculation of f will contain much less data than is represented in individual records in the database (so there are a lot more equations than unknown variables). In this case the ideal protocol is safe against a passive attack where the attacker tries to find secret information from the data he or she can see. However if the function accepts any input it might be vulnerable to a malicious attacker who lies about his data and manipulates the data in order to find secret information. This is called an active attack . In general, a protocol for calculating f is said to be safe, if any attack on it can also be performed in the ideal protocol. In practice we do not want to rely on an external party to keep the data secret. Apart from the possibility that this party has employees that are curious or malicious, even if the party itself can be trusted there is the possibility of an unauthorized person breaking into their computer systems and stealing sensitive data. So we would like to have a distributed way (protocol) for having all the parties themselves compute the function f without the parties revealing sensitive data to eachother. This may sound impossible: in order for a party to evaluate the function, it will need input from other parties. But it is possible with methods that use one of the following techniques: • Secret sharing Each party has a (random) share of the input of the others. Every calculation requires parties to perform calculations on their share. At the end of the calculation the shares are combined to retrieve the answer. Yao’s general method is an example of this type of secure computing. A well-designed secret sharing protocol can provide information theoretically secure sharing: even an adversary with unbounded computing power cannot recover the secret.

88


• (Asymmetric) cryptography This works by having parties perform calculations that combine their own data with encrypted representations of data of other parties. These calculations often use homomorphic encryption. In section 10.3 we will present a secure method for calculating the binary scalar product using this method. 10.2.2

Yao’s General Method

In [Yao82], Yao describes a general method for secure multiparty computation. In his approach, f is represented as a binary circuit, i.e. a composition of elemental boolean operators (such as XOR, NOT, AND, etc.) on the binary representation of the input variables xi . For each such operation there is a privacy-preserving distributed calculation, where each participant has a share of a single bit. The “real” bit is the result of XOR-ing these bits together, but to preserve privacy this is only actually done after the function f is calculated. As seen in computers, every calculation on bits can be represented as a binary circuit, so that Yao’s method works for all possible f . This may be a nice theoretical result, but for using this result in practice almost each intermediate operation on a single bit requires communication between the participants, which gives a lot of overhead, especially in the case of large databases. 10.2.3

Homomorphic Encryption

An encryption function for an asymmetric cryptographic scheme, e(·), is called homomorphic when: e(X + Y ) = e(X) · e(Y ).

(10.2)

Here + and · represent group operations. In practice these operations are often defined on the group Zm , so this is calculation modulo a (very large) number m. A cryptosystem is called semantically secure (see also [GLLM05]) when it is infeasible to derive information about messages from only their ciphertexts. In particular this means that it is impossible to see from ciphertext alone that several encryptions of the same plaintext belong to the same plaintext. This will be particularly important in protocol 10.3 where only single bits are encrypted. Semantic security is achieved by additionally selecting a random number r and letting the encryption function depend on r. For semantically secure homomorphic encryption we can write: e(X + Y, rX · rY ) = e(X, rX ) · e(Y, rY ).

(10.3)

An example of a semantically secure homomorphic encryption functions are Elgamal encryption (as discussed in the cryptography course). Another example is the Paillier cryptosystem and it’s improvement the Damg˚ ard-Jurik system, which can be computed more efficiently. Some other schemes exist, all of which depend on the practical difficulty of certain number theoretic calculations, such as the calculation of the discrete logarithm or integer factorization.

10.3 Mining Association Rules

89

We often make a slight abuse of notation and leave out the random number r and simply write the encryption and decryption as e(·) and d(·).

10.3

Mining Association Rules

This section describes a privacy-preserving data mining protocol for two parties that wish to perform data mining with binary attributes: each attribute can take the value 1 (the item occurs in the transaction) or 0 (the item does not occur in the transaction). Here is an example with vertically partitioned data, showing why we would want to use privacy-preserving mining of assocation rules. 10.3.1

Example

• Party one has database D1 with medical information on patients. Each attribute Disease i in the database represents the absence (0) or presence (1) of a certain disease. • Party two has database D2 where each attribute Gene i specifies the absence (0) or presence (1) of a certain gene. Now one or both parties are interested in finding rules {Genei1 , Genei2 , . . .} ⇒ Diseasej ,

(10.4)

of a gene or a set of genes whose presence imply a higher presence for the disease j, with corresponding support and confidence, which will be defined below. 10.3.2

Definition of the problem

Suppose we have a table r with schema R = {I1 , . . . In }, where Ii is a binary attribute (item). For X, Y ⊂ R, with X ∩ Y = ∅, we define the support of X: Definition 10.1 The support of the itemset X, written support(X) is the number of tuples in the database that have value 1 for every attribute in X. So in the examples where records are transactions of products bought by customers, the support can be seen as the number of transactions where a customer bought every item in the set X. In the genes/diseases example this would be the number of people who have all the genes and diseases in the set X. For an association rule “X ⇒ Y ”, we define its support as support(X ∪ Y ). We also need a measure for how significant a rule is: Definition 10.2 The confidence of the rule X ⇒ Y is given by conf (X ⇒ Y ) =

support(X ∪ Y ) . support(X)

(10.5)

90


This can be seen as the probability (in the sample data set) that a customer buying all items present in the set X also buys all the items in the set Y . The goal is to find all association rules X ⇒ Y that meet a minimum support: support(X ⇒ Y ) ≥ minsup and a minimum confidence: conf (X ⇒ Y ) ≥ minconf . We saw above that the support of a rule is equal to the support of the set containing all the items occurring in the rule. This means we should find itemsets that meet this minimum support. We will call these sets frequent. The confidence of a rule can be calculated from the supports of two itemsets. So a data mining algorithm will typically search for all the frequent itemsets Z, and then use these to generate rules by looking at different partitions of such a set Z into two parts: Z = X ∪ Y , to get the rule X ⇒ Y . By the above, the support and confidence of such a rule can be calculated from support(X) and support(X ∪ Y ). Because —by a rule given below— the subset X must also be frequent we can assume that the algorithm already calculated the support of X. Hence we can calculate the confidence of the rule. Because the generation of rules from the set of frequent itemsets is rather straightforward we shall discuss an algorithm for finding the frequent itemsets. Suppose Alice, Bob, Charles, etc. . . wish to perform privacy-preserving mining of association rules. There are two ways the data can be partitioned: • Horizontally. In this case support(X) = support Alice (X) + support Bob (X) + support Charles (X) + . . . (10.6) No data about individual records needs to be shared to calculate this. There is one potential problem though: Alice might have frequent itemsets which aren’t frequent on the total data. [KC04] has a secure solution for this problem. Here we will focus on vertically partitioned data. • Vertically. We restrict ourselves to two parties, Alice and Bob, so X = XAlice ∪ XBob . Let DAlice (k, I) denote the bit of Alice’s database at the row with identifier k and attribute (item) I. Similarly for Bob. Then

support(X) = # records with value 1 for each item in XAlice ∪ XBob X Y Y = DAlice (k, I) DBob (k, I) (10.7) k

I∈XAlice

I∈XBob

Simply put: for each row in the joint table, calculate the product of the value of each attribute occurring in X, and sum the results. For a given row, this product is only 1 when all attributes in X have value 1, so that only then this row contributes to the support Q of X. Mathematically this is a binary scalar product between the vector vk = I∈XAlice DAlice (k, I) owned by Alice, and a similar vector owned by Bob. When all the items in X are in Alices database (i.e. XAlice = X


91

function apriori : F1 ← frequent 1-item sets i←2 while Fi−1 6= ∅ do Ci ← apriorigen(Fi−1 ) for each c ∈ Ci do compute and store support(c) Fi ← {c ∈ Ci |support(c) ≥ minsup} i←i+1 return ∪i Fi

Algorithm 10.1: A priori algorithm for association rule mining

and XBob = ∅) Alice can calculate the scalar product without the need for a secure scalar product protocol. The same goes for the case that X = XBob . When both XAlice and XBob contain just one item, the scalar product is between single columns in the two databases. If an itemset Y is frequent, then a given subset X ⊂ Y has at least the same support: someone who buys all the items in Y certainly buys all the items in X. So every subset of a frequent itemset is frequent. This property is exploited in the a priori algorithm for finding frequent itemsets. Its pseudo code (written in a way so that the lines where privacy-preservering calculation is needed are easily identified) is given in 10.1. 10.3.3

A solution: the a priori algorithm

The algorithm first calculates all frequent 1-item sets and puts all of them in the set F1 . This calculation can be done by Alice and Bob separately as it only involves one item. Next, a while loop is entered, starting with the counter value i = 2. Because of the rule discussed above, we see that every frequent i-item set needs to contain two

function apriorigen(F (i)): C←∅ for each pair of sorted itemsets X, Y ∈ F (i) that shares i − 1 items do sort the items in X ∪ Y and add to the set C . This can still generate the same candidate item set more than once. . Because C is a set it will contain it only once. return C

Algorithm 10.2: Function for generating candidate itemsets

92


frequent (i − 1)-item sets that share all but 1 new item. A set of candidate i-item sets is generated using Fi−1 , and put in the set Ci . This generation is done in the apriori-gen subroutine shown in algorithm 10.2. To prevent the generation of too many of the same i-item sets we require every i − 1 item set to be sorted in a predefined order. Note that this generation can be done either by Alice or Bob without the need for a secure protocol. Now we have the new candidate set, we still need to check if the generated candidate item sets are indeed frequent. This is done in the next three lines of the algorithm. Here, we need to compute the support of a candidate item set. If the item set contains both items from Alice and Bob, we can do this using a secure scalar product protocol. There are no other places in the algorithm where we need a secure protocol. We will discuss two possible protocols in the next section. Finally, the algorithm stops when no more frequent item sets can be found, and it returns every frequent itemset it has found. We clarify the working of the a priori algorithm by showing how it acts on a small example database. We use the data given in table 10.1. Table 10.1: An example. Attributes I1, I2 and I3 are known to Alice, I4, I5 and I6 are known to Bob. Id I1 1 1 2 0 3 0 4 0 5 0 6 0 7 1 8 0 9 0 10 0

I2 I3 I4 I5 I6 0 1 0 1 0 0 0 0 1 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 0 1 0 0 0 0 0 0 0 1 0 1 1 1 0 0 0 1 0 1 0 1 1 1

Id I1 I2 I3 11 0 1 0 12 0 0 0 13 0 0 1 14 0 1 0 15 0 1 0 16 0 0 1 17 0 0 0 18 0 0 0 19 1 1 1 20 0 1 1

I4 I5 1 1 1 0 1 0 1 1 1 1 0 1 1 1 0 1 1 1 1 0

I6 1 0 0 0 0 0 0 1 0 0

Suppose we take a minimum support of 6, Alice has data about the attributes I1, I2 and I3, and Bob has data about I4, I5 and I6. The first step is to generate the frequent 1-item sets. Alice and Bob calculate the supports for their single items by counting the number of ones in each column of the table. This is shown in table 10.2. Only items with a minimal support of 6 are accepted and put in the set F1 . Next, the two-item candidates are calculated by combining the frequent items of table 10.2. Because for example {I2 , I3 } = {I3 , I2 } the sets are generated by ordering with respect to item number. For calculating the support of some of the two-item sets Alice and Bob need to perform a secure scalar product calculation. The results are shown in table 10.3. Finally, there is only one three-item candidate set that is calculated by combining and sorting of frequent two-item sets that share one item. It is shown in table 10.4.


93

Table 10.2: First step of the a priori algorithm 10.1 with minsup = 6, for the example data in table 10.1. These are one-item sets with their support. They can be calculated by Alice and Bob separately. candidate set {I1 } {I2 } {I3 } {I4 } {I5 } {I6 }

calculated by A A A B B B

support frequent? 3 no 10 yes 6 yes 14 yes 14 yes 5 no

Table 10.3: Two-item sets as found by the a priori algorithm 10.1 with minsup = 6, for the example data in table 10.1. These are two-item candidates with their support. candidate set {I2 , I3 } {I2 , I4 } {I2 , I5 } {I3 , I4 } {I3 , I5 } {I4 , I5 }

calculated by A A&B A&B A&B A&B B

support frequent? 3 no 10 yes 7 yes 4 no 3 no 9 yes

94


1. Alice has a binary vector (x1 , x2 , . . . , xn ). 2. Bob has a binary vector (y1 , y2 , . . . , yn ). 3. Alice generates a public and private key pair for a semantically secure homomorphic encryption scheme e(·) with decryption d(·), and sends the public key to Bob. 4. Alice calculates and sends (e(x1 ), e(x2 ), . . . , e(xn )) to Bob. Q 5. Bob generates a random number R, calculates w = e(R) i e(xi )yi and sends the result to Alice. P 6. Alice calculates s = d(w) = R + i xi yi . Protocol 10.3: Protocol for SSP computation ([WY04], [WYS06])

The algorithm returns all frequent itemsets found in the three tables, so that another algorithm can generate rules that meet some minimum confidence. Table 10.4: The only three-item set candidate as found by the a priori algorithm 10.1 with minsup = 6, for the example data in table 10.1. candidate set {I2 , I4 , I5 }

10.4

calculated by A&B

support frequent? 7 yes

Secure Scalar Product Computation

We discuss two different protocols. We show that the second protocol appears to be a special case of the first. The papers where we found these protocols do not explicitly mention if we should use all calculations to be modulo a very large number n as used in the encryption scheme. This seems clear because we are multiplying ciphertexts. We shall at least assume this in the first protocol, but for the second protocol we aren’t really sure this is actually meant by the authors. It seems to give problems as we will discuss below. For the first protocol there is no danger that the resulting scalar product is larger than n because n is typically a number of 512 bits or more. In their paper about privacy-preserving generation of Bayesian networks ([WY04]), Wright and Yang suggest a protocol for secure scalar product (SSP) computation. It is given in protocol 10.3. Proposition 10.3 Protocol 10.3 correctly calculates the scalar product (up to R).

10.4 Secure Scalar Product Computation

95

1. Alice has a binary vector (x1 , x2 , . . . , xn ). 2. Bob has a binary vector (y1 , y2 , . . . , yn ). 3. Alice generates a public and private key pair for a (possibly not semantically secure!) homomorphic encryption scheme e(·) with decryption d(·), and sends the public key to Bob. She also chooses an integer number X greater than N (i.e., the number of transactions) and sends this to Bob. 4. Alice randomly generates independent integer numbers Ri and sends e(xi + Ri X) to Bob. Q 5. Bob calculates w = i,yi 6=0 e(xi + Ri X) and sends the result to Alice. P 6. Alice calculates s = d(w) mod X = i xi yi Protocol 10.4: Secure Two-Party Protocol as suggested by [ZMC05]

Proof. By the homomorphic property of the encryption function we have ! Ã X Y d (e(xi )yi ) . d(w) = d e(R) e(xi )yi = R + i

(10.8)

i

There are two possibilities for the term d (e(xi )yi ). 1. yi = 0. In this case e(xi )yi = 1, so this factor doesn’t contribute to our original product and it can’t contribute to the sum either (d(1) must be 0 for homomorphic encryption). So d (e(xi )yi ) = 0 = xi yi . 2. yi = 1. Here we have e(xi )yi = e(xi ). So d (e(xi )yi ) = d(e(xi )) = xi = xi yi . 4 Alice knows the random R, so when Bob needs to know the result too she can send it to Bob. In their paper [ZMC05], Zahn et al. made the assumption that 0 and 1 always encrypt to the same cyphertext, claiming this as a great security flaw in protocol 10.3. Instead they devised the new protocol 10.4. It seems clear that Zahn et al. were explicitly trying to achieve the fact that several encryptions of 0 and 1 are indistinguishable from eachother (semantic security). Proposition 10.4 Protocol 10.4 correctly calculates the scalar product.

96


Proof. Ã d(w) mod X = d

Y

! e(xi + Ri X)

mod X

i,yi 6=0

=

X

d(e(xi + Ri X))

mod X

i,yi 6=0

=

X

(xi + Ri X)

i,yi 6=0

=

X

i,yi 6=0

xi =

X

mod X

xi yi .

(10.9)

i

4 Both these protocols correctly calculate the scalar product. In fact the second protocol is very similar to the first which we can see by using the following proposition. Proposition 10.5 Let e be a (possibly deterministic) homomorphic encryption function. Then the function e0 defined as e0 : x, r → e(x + rX) is also homomorphic. Proof. The new function e0 satisfies e0 (x + y, rx + ry ) = e(x + y + (rx + ry )X) = e(x + rx X + y + ry X) = e(x + rx X)e(y + ry X) = e0 (x, rx )e0 (y, ry ). (10.10) This means that e0 is a homomorphic function, where parameter r uses as its group operation addition of numbers. 4 So this new randomized encryption function e0 is again homomorphic. If we take the calculations as being reduced modulo n we run into a few problems with it. In particularly Zahn et al. did not specify the range for the random numbers r used for calculating the plaintext xi + Ri X. Taking the number r randomly from the set Zn , and chosing the number X (in advance) so that r → rX has as its range all of Zn would give a perfect semantic security. However, the encryption function e0 keeps no data about the random number r (for example Elgamal encryption keeps g r with g a generator of the group). Because xi + Ri X can now be any given plaintext, the resulting ciphertexts are indistinguishable, even for someone knowing the decryption key for e! Choosing the Ri this way, we cannot expect the decryption to give the right answer! Maybe the random numbers Ri can be chosen small so that the xi + Ri X don’t become too large, but this could be a problem for semantic security. Q It could also be that Zahn et al. meant the number w = i,yi 6=0 e(xi + Ri X) NOT to be reduced modulo n, meaning that a very large number is calculated and sent back to Alice, but this is not how encryption and decryption works. If the encryption for example is 1024 bits w would be of the order of 1024 times the size of the vectors, the same size Alice has to send to Bob, so this in itself might not be a large problem. But now the chosen asymmetric encryption scheme must have a decryption function that can act on an arbitrary large number. This means the encryption function must be

10.4 Secure Scalar Product Computation

97

able to do this too, so we should have used some kind of a block encryption/decryption scheme! If we ignore all of these issues, we see that both protocols in fact look the same (apart from the one random number R chosen by Alice in the first protocol): if we replace e by e0 in the first protocol we get the second. In their paper [GLLM05] Goethals et al. show that protocol 10.3 is secure against passive attacks. In a passive attack the attacker tries to find secret information from the data he or she sees. In an active attack , the attacker also manipulates the data in order to find secret information. 10.4.1

Active Attacks

One of the first active attacks one has to be aware of in both protocols, is a chosen ciphertext attack (CCA) by Bob. The result of the scalar product computation is a decryption that Alice performs on a ciphertext she received from Bob, so she must be aware of Bob trying a CCA attack. In the extreme case, Bob could be able to make a carefully constructed ciphertext that reveals Alice’s secret key. Fortunately, a simple measure against this is first checking the range of the decrypted scalar product before sending the result to Bob. It must be in the range 0 ≤ s ≤ l, where l is the size of the vector. Because the number of possible decryptions of a ciphertext (e.g. 21024 for 1024 bits encryption) is astronomically larger than the number of rows in any database table, the probability for this kind of CCA happening is negligable. However, we found two other possible active attacks which will be described below. Proposition 10.6 When Bob exactly follows protocol 10.4, then Alice can make a choice for the “random” numbers Ri so that she can easily calculate all the values of Bob’s vector. For the proof we make use of the following: Definition 10.7 A sequence (Ri )i≥0 of real numbers is superincreasing if Ri+1 >

i X

Rj for every i ≥ 0.

(10.11)

j=0

For example, for every k ≥ 2, the sequence Ri = k i —as used for digits in number notation—is a superincreasing sequence. With this definition we can now prove equation 10.6: Proof. Suppose Alice chooses a superincreasing sequence for Ri ≥ 2i , instead of random numbers. Because Bob follows the protocol, Alice receives the number Y w= e(xi + Ri X). (10.12) i,yi 6=0

As in the proof of proposition 10.4, Alice now calculates d(w), but does NOT reduce modulo X: X X d(w) = (xi + Ri X) ≤ (1 + Ri X). (10.13) i,yi 6=0

i

98


(If (see the discussion above) the calculation of w is taken to be modulo n the above only works if the numbers xi + Ri X aren’t too large for the second term of d(w) to be larger than n.) We can assume that Alice and Bob do not start the protocol for a vector of length 0, so we know that X is at least 2, so that the sequence 1 + Ri X is superincreasing. Now suppose d(w) ≥ Rn X. Because 1 + Ri X is superincreasing, the sum over all terms with i < n in the above equation is less than xn + Rn X. This can only mean that the term xn + Rn X is present in the sum, so that yi = 1! Alice of course knows her own value xn , so she can calculate d0 (w) = d(w) − xn − Rn X. If however d(w) < Rn X Alice knows for sure there isn’t a term for n, so she can put d0 (w) = d(w). Now Alice can perform the same trick for n0 = n − 1 on d0 (w) to find out yn−1 . She can keep doing this until n0 = 0, and thus finds every single bit yi of Bob’s vector. 4 that the expression Q it is easy to ysee Q Because of the binary character of the vectors, i i e(xi + Ri X) . Combining this with i,yi 6=0 e(xi + Ri X) in protocol 10.4 is equal to proposition 10.5, we see that the two protocols are essentially equivalent, up to the specific choice of asymmetric encryption function. We have shown that protocol 10.4 is insecure to an active attack. This immediately raises the question: if we use a semantically secure homomorphic encryption schemes such as Elgamal with protocol 10.3, does it suffer from a similar kind of attack? Could the “random” numbers used in the encryption scheme be chosen so that information about Bob’s vector can be retrieved? This is something which should be further investigated for schemes such as Elgamal and Paillier, but goes beyond the scope of this paper. We also found a simple vulnerability that is already present in the ideal protocol: Proposition 10.8 The ideal two-party secure scalar protocol is vulnerable to an active attack yielding the value of one single record. Proof. Suppose Alice has vector xi and plays fair, but Bob wishes to know the value of xk for certain k. Bob follows the protocol, but uses theP vector yi where yi = 0 for every i except i = k. Then Bob learns the result xk because i xk yk = xk yk = xk . 4 Corollary 10.9 Every two-party scalar protocol that accepts any input is vulnerable to an active attack. Of course it is also possible that Bob is not cheating, but really has a vector with only one nonzero component. In any case it would be useful to develop a protocol which refuses to work when either party’s vector has only a few values of 1; let’s say a minimum of m values. For the problem of association rule mining we can simply take m = minsup, the minimum amount of values in either vector must be larger or equal than the minimum support anyway, in order for the rule to meet the minimum support. In the a priori algorithm 10.1 such a rule will not be considered if Alice or Bob are at most passive attackers. But of course, one of them could try an active attack during the scalar product protocol, so there is still the need for a safety mechanism. In assocation rule mining, one simple way for Alice to protect herself is counting the number of ones in the vector she sends to Bob (is it lower than minsup?). Alice or Bob cannot simply tell

Summary and Conclusions

99

the amount of ones in their vector (or use a secure solution to Yao’s millionaire problem to prove the amount is higher than m without giving it away) because they could lie. In conclusion: a smart way for Bob to prove that the minimum amount of ones is met in the encrypted vector he receives from Alice, is needed. This should be investigated further. Even if this turns out to be impossible, a solution which is possibly acceptable in practice is to simply stop the execution of the whole algorithm whenever one of the parties is found to be cheating, so that only one bit of data of at most one attribute of one individual can be found out by the other party. Of course this can still sometimes be a serious issue; for example when it is found out that a certain well-known individual has some awkward disease.

Summary and Conclusions The secure calculation of the scalar product is an important subroutine in many privacypreserving data mining tasks, we have shown its use for the secure mining of association rules. It can in principle be calculated with Yao’s binary circuit method, but the most practical way is probably by using homomorphic encryption. The speed has been tested in practice and found to be too slow for some applications, but fast enough for other applications. The work by [GLLM05] gives some optimization tips for calculating the scalar product using protocol 10.3. In particular they suggest precomputing a table of encryptions e(0) and e(1). We have shown that the ideal protocol for secure scalar product computation is insecure to a simple active attack yielding one attribute of the other party’s vector. It has been proved by [GLLM05] that the encryption-based scalar protocol as given in [WY04] is safe against passive attackers (attackers that strictly follow the protocol but are curious and try to decrypt data they get from the other party). Zahn et al. devised an alternative protocol ([ZMC05]). They claim that the protocol by [WY04] contains a trivial passive attack, but this is not true because they did not realize the used encryption scheme is semantically secure. Instead we have shown that their protocol is not well-defined and may be very vulnerable to an active attack yielding all of the other party’s total vector by choosing special “random” numbers. This raises the question if the protocol by [WY04], depending on the used homomorphic encryption scheme, may be insecure against similar active attacks yielding multiple elements of the other party’s vector. We suspect that there are ways to adapt the protocol with standard secure computation methods to improve its security against active attackers. This is an important point that should be addressed in further research. In “real-life” applications one can never rely on users not being active attackers, so this problem should certainly be addressed before using the protocol in an actual computer application.

100


Hoofdstuk 11 Loterijen Door Ruben van der Zwaan

Veel geld gaat rond in de wereld van loterijen, in de grootste Nederlandse loterijen1 alleen al gaat ongeveer één miljard euro rond. Deze grote loterijen zijn onlosmakelijk verbonden met groots opgezette tv shows. Deze shows zijn zeer duur om te produceren, desondank hebben al deze loterijen verschillende spelvormen en shows voor op de tv. De Nationale Postcode Loterij heeft bijvoorbeeld de volgende programma’s: • Lingo (Zie Casus 11.1) ´ en tegen honderd • E´ • Miljoenenjacht • Deal or No Deal • Postcodekanjer Journaal 2006 • Oranje Fonds: 5 jaar jong, 60 jaar oud. Bij veel loterijen gebeurt de trekking nog met een mechanische machine. Voor een nieuwe spelvorm wordt vaak een nieuwe tv show gemaakt, en dit wordt uitgezonden op televisie. Een probleem met mechanische trekkingen is dat de introductie van nieuwe spelvormen duur is. Een nieuwe machine moet gebouwd worden en getest. Hoogstwaarschijnlijk is een nieuwe show nodig, passend bij de machine. Naast de dure introductieprijs van een nieuwe spelvorm, is het door de kosten van een uitzending niet haalbaar om meerdere keren per dag trekkingen te verrichten. Toch zijn er ook voordelen aan de huidige opzet van loterijen, door de rechtstreekse uitzending kan de deelnemer zichzelf ervan overtuigen dat de loterij eerlijk verloopt. Het 1

Staatslotterij, Lotto, Nationale Postcode Loterij

101

102

Loterijen

Kader 11.1: Lingo Lingo is een spel op de televisie, waar twee teams woorden van een vaste lengte moeten raden. De beginletter wordt gegeven, en teams mogen vijf keer raden bij elk woord. Hebben ze het woord niet binnen vijf pogingen geraden, dan mag het andere team, met een bonus letter. Na elk goed geraden woord moet een bal uit de ballenbak worden gehaald. Er zijn genummerde, rode en groene ballen. Bij een genummerde bal wordt op een grid met nummers erop, het vakje met het getrokken nummer erin, weggestreept. Trek je een rode bal, dan is het andere team, een groene bal betekent dat je het volgende woord mag beginnen te raden. Het team wat de meeste woorden goed heeft, gaat door naar de finale. In de finale moeten veel woorden snel achter elkaar worden geraden. Midden in het programma kondigt de presentatrice (Lucille Werner, foto) een dagpostcode aan. Iedereen die meespeelt met de Nationale Postcode Loterij met die postcode, wint duizend euro. doel van een elektronische loterij is het implementeren van alle voordelen van mechanische loterijen, maar dan met lage trekking kosten, en het goedkoop introduceren van nieuwe spelvormen. Er zijn verschillende aanvallen mogelijk op loterijen. Door de hoeveelheid geld die er omgaat in loterijen, zou al één keer misbruik een loterij kunnen ruineren. In de volgende sectie zullen verschillende aanvallen besproken worden. In sectie 11.3 zal een daadwerkelijk geimplementeerde elektronische loterij besproken worden. De verschillende eigenschappen van loterijen zijn te vinden in sectie 11.2. Voor elektronische loterijen zijn verschillende technieken nodig. Voor zover deze niet elders in dit boek zijn beschreven, is uitleg te vinden in de sectie over de gebruikte technieken. Omdat er veel verschillende manieren zijn om bijvoorbeeld ’trekking’ en ’deelnemer’ te verwoorden, zal door het hele hoofdstuk de volgende termen worden gebruikt: Trekking Het proces om een uitslag te verkrijgen. Organisator De organisator van de loterij. Loterij Een loterij georganiseerd door een organisator. Deelnemer Een persoon die een lot in zijn bezit heeft.

11.1 Aanvallen

103

Kader 11.2: Systemen voor het voorspellen van loterijen Een kleine selectie van tips, om je kansen op winst te vergroten. De tips zijn door mensen bedacht, en totaal niet onderbouwd. Op z’n best zijn de tips dubieus, en de auteur aanvaard geen enkele verantwoordelijk voor verlies. Merk op dat tip 2 en 3 elkaar tegenspreken. 1. Neem geen reeksen van achtereenvolgende getallen, zoals 1, 2, 3, 4, 5, 6, want de kans dat deze reeks getrokken wordt is bijzonder klein. 2. Met slechts een klein aantal(10) of hoogstens vijftig uitslagen kan je winnende nummers vaststellen. De meeste getallen die in de meest recente trekking voorkwamen, zaten ook in een aantal trekkings uitslagen daarvoor. 3. Kies getallen die nog niet vaak getrokken zijn, en kies deze. De kans dat deze getrokken worden is groter dan als ze hiervoor al getrokken zijn. (Vrij vertaald van http://www.lottery-results-info.com/lottery-tips.html)

11.1

Aanvallen

Er zijn verschillende aanvallen mogelijk op loterijen. De makkelijkste is de uitslag voorspellen van de volgende trekking. Deze aanval is toegestaan, maar de loterij zal er voor proberen te zorgen dat de uitslagen niet te voorspellen zijn. Menigeen zoekt verwoed naar een systeem om de volgende trekking te voorspellen, en (multi-)miljonair te worden. Zie Casus 11.2 voor een voorbeeld van systemen voor het voorspellen van loterij uitslagen. Een niet toegestane vorm van een aanval is het manipuleren van het trekkingsproces, zodat jouw lot en winnend lot is. Voor shows waar het trekken met een machine plaatsvind, rechtstreeks op de televisie, is dit grotendeels geen probleem. Immers, de hele trekking staat op video, dus achteraf kunnen alle handelingen nagelopen worden. Toch is het mogelijk dat iemand in beeld het proces toch weet te manipuleren. Met het inzetten van notarissen voor controle en toezicht proberen loterijen dit te ondervangen. Een wat slimmere aanval, is een lot invullen nadat de trekking bekend is. Daarna dit lot in de stapel met loten stoppen. Achteraf is niet meer te controleren of er vals is gespeeld. Met een waarmerk op alle loten, of een speciaal soort telling van de loten kan dit achteraf gecontroleerd worden. Het tellen van de loten is geen oplossing, omdat het weghalen van een lot geen probleem is, als het erin stoppen ook geen probleem is. Alle genoemde aanvallen kunnen natuurlijk ook, en misschien wel efficienter, uitgevoerd worden op elektronische loterijen. Een handtekening van papier kopieren is moeilijk, maar een rij eenen en nullen kopieren is makkelijk.

104

Loterijen

11.2

Eigenschappen van loterijen

Er zijn eigenschappen waarvan we graag zouden willen dat een loterij deze zou hebben. Voordat we zullen aantonen dat deze eigenschappen gewenst zijn, definiëren we eerst eigenschappen van de organisatoren en de deelnemers van loterijen. Definitie 11.1 Een organisator streeft naar zoveel mogelijk winst uit een loterij. Definitie 11.2 Een organisator streeft naar gelijke kansen voor elke deelnemer in de georganiseerde loterij. Definitie 11.3 Een deelnemer streeft naar een zo hoog mogelijke opbrengst van zijn/haar lot. Aan een loterij systeem kunnen eisen worden gesteld, deze eisen worden ook beargumenteerd waarom ze nodig zijn, om het systeem veilig te maken. Stelling 11.4 De uitslagen moeten een uniforme distributie hebben, dat wil zeggen dat de elke uitslag even vaak voorkomt. Bewijs. Het is vrij gemakkelijk in te zien, dat als bepaalde uitslagen veel vaker voorkomen, dat deze vaker gekozen gaan worden (Definitie 11.3). Dit betekent dat de organisator inkomsten mis loopt. Volgens definitie 11.1 streeft een organisator naar een zo hoog mogelijke winst. Dus de loterij uitslagen moeten uniform gedistribueerd zijn. 4 Stelling 11.5 De kans om de volgende uitslag correct te voorspellen, is hoogstens hetzelfde als de kans op een willekeurige uitslag. Bewijs. Zodra de kans om de volgende uitslag te voorspellen beter is dan de kans op een willekeurige trekking, zal de deelnemer de uitslag proberen te voorspellen (Definitie 11.3). Een hogere kans op meer opbrengsten voor de deelnemer, betekend minder inkomsten voor de loterij. Doordat loterijen naar zoveel mogelijk winst streven (Definitie 11.1), moet ook hieraan voldaan worden, voordat de organisator van de loterij tevreden is. 4 Het lijkt misschien dubbelop: en een uniforme distributie en niet voorspellen. Stel er is een loterij, en er wordt een getal tussen 0 en 9 getrokken. T (i) is de i’de trekking van de loterij. Een voorbeeld van een loterij, waarvan de uitslagen wel uniform gedistribueerd zijn, maar desondanks voorspelbaar zijn: T (i) = i modulo n. De uitslagen volgen dus een vaste reeks 0, 1, 2, 3, 4, 5, ...., ondanks het feit dat de trekkingen uniform gedistribueerd zijn, is het vrij makkelijk te voorspellen. De eis van onvoorspelbaarheid impliceert wel de eis van uniforme distributie, maar andersom niet. Een theoretische loterij, waarvan de trekkingen niet uniform gedistribueerd zijn, en niet voorspelbaar: T (i) = rand(0, 10). De trekking is niet te voorspellen, er zit geen vaste volgorde in, maar alleen de getallen 0 en 1 worden getrokken. De kans om de goede trekking te voorspellen is vijftig procent, de kans op een willekeurige mogelijke trekking is tien procent. Dit betekend dat deze loterij toch voorspelbaar is. Dus zo’n soort loterij kan niet bestaan.

11.3 Implementatie van een Elektronische Loterij

105

Stelling 11.6 Het mag niet mogelijk zijn de trekking of de loten te manipuleren. Bewijs. Het manipuleren van de trekking of loten door een deelnemer, heeft hetzelfde effect als bij het voorspellen van de uitslagen. Hierdoor loopt de loterij geld mis, wat in tegenspraak is met Definitie 11.1. Manipulatie van de trekking of loten door de loterij zelf is ook onwenselijk, omdat de deelnemer een zo hoog mogelijke opbrengst wilt (Definitie 11.3). Alle belanghebbenden willen een niet te manipuleren loterij. 4 Stelling 11.7 Het proces van trekkingen moet achteraf en tijdens het proces te controleren zijn. Bewijs. Als het trekkingsproces niet te controleren is, zal geen enkele deelnemer overtuigd zijn dat het systeem niet te manipuleren is. Nou is dit voor een persoon die wilt valsspelen een pré, maar voor de ’eerlijke’ deelnemer is dit onwenselijk (Definitie 11.3). Het is dus ook in het belang van de loterij, die zoveel mogelijk deelnemers wenst, voor zoveel mogelijk winst (Definitie 11.1). Deze eigenschap is ook belangrijk om manipulatie tegen te gaan. 4 Stelling 11.8 De specificaties van de loterij moeten openbaar zijn. Bewijs. Dit bevorderd het vertrouwen in de loterij, omdat zo het systeem te controleren is voor iedereen. Kerckhoffs’ Principe2 houdt kort in dat de specificatie en werking van ´ en van de redenen is dat alles uiteindelijk toch het systeem aan iedereen bekend zijn. E´ uitlekt. De veilligheid van het systeem kan beter van andere dingen afhangen (Zie de voorgaande eisen), dan de geheimhouding van het systeem. 4

11.3

Implementatie van een Elektronische Loterij

Twee elektronische loterijen maken reclame met het feit dat het elektronische loterijen zijn. De nationale loterij van Puerto Rico en een loterij in het Dominicaanse Republiek3 . Beiden geven geen informatie over het achterliggende systeem en methodiek. Ook het bedrijf wat elektronische loterijen verkoopt (zie Casus 11.3) geeft geen inhoudelijke informatie. Er is een elektronische loterij waarvan de informatie wel beschikbaar is, en die gebruikt wordt in een nationale loterij. Dit systeem wordt beschreven door Konstantinou etal [K+ 04]. Over systemen voor poker en andere gokspellen is al veel geschreven [HS97], maar deze methoden zijn vaak niet geschikt voor zeer veel deelnemers, zoals een nationale loterij. 2 3

Zie pagina 4, Cryptografie dictaat. www.leidsa.com

106

Loterijen

´ nica de Puerto Rico Kader 11.3: Loter´ıa Electro In 2004 tekende de overheid van Puerto Rico een contract met Scientific Games Corporation [Sci04] om de nationale loterij te automatiseren. De loterij van Puerto Rico heeft ongeveer een jaaromzet van 340 miljoen dollar, en voor 70 miljoen dollar werd een nieuw systeem, en zeven jaar onderhoud gekocht van Scientific Games Corporation. Al na zes maanden was het nieuwe systeem doorgevoerd [Sci05], de geschatte winst t.o.v. van het oude systeem word geschat op 70 miljoen dollar over zeven jaar (Dit betekend 140 miljoen extra omzet, en 70 miljoen aan extra kosten voor het systeem). Dit toont aan dat de winst door automatisering, die door verscheidende papers wordt verondersteld, ook werkelijkheid en realistisch is. Scientific Games Corporation: www.scientificgames.com. Loter´ıa Electrónica de Puerto Rico: www.loteriaelectronicapr.com (Spaans).

11.3.1

De Loterij

De elektronische loterij van [K+ 04] noemen we verder in deze sectie gewoon ’de loterij’. In ongeveer 6000 postagentschappen kunnen loten ingeleverd worden, om mee te doen voor de volgende trekking. Deze loten worden elektronisch naar het hoofdkantoor van de loterij organisator gestuurd. De loterij heeft vele trekkingen per dag. Het systeem om trekkingen te verrichten bestaat uit twee verschillende onderdelen: de controleur en de generator. Het is de bedoeling dat met beide onderdelen geknoeid moet worden, om een uitslag blijvend te manipuleren. Beide onderdelen houden een logboek bij. De controleur ontvangt alle loten van het hoofdkantoor, maakt een hash van alle loten, en stuurt deze uiteindelijk naar de generator. De controleur rekent de generator helemaal na, zodat de uiteindelijke uitslag gecontroleerd is. Als de uitslagen niet overeen komen, geeft de controleur een waarschuwing. De controleur heeft ook een rechtstreekse verbinding met de televisie, zodat uitslagen meteen op de televisie kunnen verschijnen. Elke keer als informatie naar het hoofdkantoor wordt verstuurd, worden deze gegevens ook naar het televisie station gestuurd. Een tekortkoming in de opzet van Konstantinou etal is dat pas bij controle van het logboek van de generator, geconstateerd kan worden of er met de controleur geknoeid is. Dit is te voorkomen door ook de generator een verbinding met het hoofdkantoor te geven. De taak van de generator is om met behulp van ’pseudo-random’ en ’true random’ generatoren de getallenreeks van de uitslag te genereren. Zie sectie 11.4.2 voor meer informatie over random getallen. De hash4 van alle loten wordt door de generator gebruikt voor het genereren van de uiteindelijke uitslag. Nadat het hoofdkantoor de uitslag heeft ontvangen, kunnen de winnende loten ge4

Zie de hoofdstukken over SHA1, MD5 en SMASH

11.3 Implementatie van een Elektronische Loterij

107

selecteerd worden. De aanval die na de uitslag een lot toevoegd, is niet mogelijk. Door het maken van een hash file van alle loten voor de trekking, kan achteraf gecontroleerd worden of de loten niet gemanipuleerd zijn. 11.3.2

Protocol

In de tabel hieronder staat het protocol stap voor stap beschreven, stap elf is een stap die niet in [K+ 04] staat, maar ons inziens wel noodzakelijk is. Bij het achterwege laten van stap elf, kan als alleen de controleur gecompromiteerd is, een foute uitslag naar het hoofdkantoor verstuurd worden. Nu moeten én de generator én de controleur gecompromiteerd zijn voordat het hoofdkantoor een foute uitslag ontvangt. Stap Generator Controleur 1 Ontvangt de loten en maakt een hash H hiervan. 2 Genereert een reeks willekeurige getallen R, met ’true random’ generatoren. 3 Stuurt een Commit van R, C(R) op (Zie 11.4.1) Ontvangt Commit. 4 Ontvangt een hash H Stuurt H op 5 Gebruikt R en H als input van de pseudo random generatoren, trekking = ρ(R + H). 6 Stuurt de trekking op. Ontvangt trekking 7 Stuurt R naar de Controleur Ontvangt R 8 Controleert of C(R) = Commit 9 Controleert of trekking = ρ(R + H). 10 Slagen alle controles, stuurt trekking op naar het hoofdkantoor. 11 Stuurt trekking op naar het hoofdkantoor. 11.3.3

Eigenschappen

Dit systeem voldoet aan alle gewenste eigenschappen uit Sectie 11.2, zoals uit de voorgaande paragrafen blijkt: Uniforme verdeling (Eigenschap 11.4) Dit wordt gegarandeerd door de manier waarop de uitslag tot stand komt. Niet te voorspellen (Eigenschap 11.5) Dit wordt gegarandeerd door de manier waarop de uitslag tot stand komt. Niet te manipuleren (Eigenschap 11.6) Er moeten minsten twee onderdelen van het systeem gemanipuleerd worden voordat dit kan, en achteraf kan het ook nog gecontroleerd worden.

108

Loterijen

Kader 11.4: Bassie en Adriaan en de Afwas Bassie en Adriaan hebben al een week niet afgewassen, op zich geen probleem want Robbie wastte normaal altijd af. De snode Baron heeft echter niet stilgezeten, en heeft Robbie gebotnapped. Ze spreken af dat één van beiden Robbie gaat redden, en de ander moet afwassen. Bassie stelt voor dat hij een getal in gedachten neemt, en Adriaan moet raden of het getal even of oneven is. Adriaan ziet dit absoluut niet zitten, Bassie is een clown en totaal niet te vertrouwen, die gaat vast valspelen. Na wat nadenken kom Adriaan met een kistje en een papiertje. Bassie moet het getal op het papiertje schrijven, en in het kistje stoppen. Dit kistje gaat op slot, en Bassie houd de sleutel. Het afgesloten kistje word aan Adriaan gegeven, die na ontvangst mag raden. Zodra Adriaan zijn keuze aan Bassie bekend heeft gemaakt, en Bassie de uitslag doorgeeft, geeft Bassie de sleutel aan Adriaan. Adriaan kan nu controleren of Bassie eerlijk speelt. Het kistje is hier de commit boodschap, en het cijfer de echte boodschap. Controleerbaar (Eigenschap 11.7) Alle onderdelen houden logboeken bij, en sturen informatie naar het hoofdkantoor. Openbaar (Eigenschap 11.8) De specificatie is gepubliceerd.

11.4

Technieken

Het commitment protocol, in de literatuur ook wel bit commitment genoemd, wordt als eerste uitgelegd. Over random getallen is er ook een klein stukje, namelijk het verschil tussen ’true’ random generatoren en pseudo random generatoren. 11.4.1

Commitment Protocol

Een commitment protocol is een methode zodat een partij zich op informatie kan vastleggen bij een andere partij, zonder dat de andere partij de geheime informatie kan achterhalen. Achteraf kan de ontvanger controleren, na ontvangst van de geheime informatie, of de verzender zich inderdaad op deze geheime informatie heeft vastgelegd. Voor een voorbeeld, zie Casus 11.4. Zie [Syv98] en [Tel06] voor meer informatie. 11.4.2

Random getallen

Random getallen kunnen op twee manieren geproduceerd worden, door de pseudo random generator of een ’true’ random generator.

11.5 Samenvatting

109

Een ’true’ random generator is een generator die uit een proces informatie haalt, en dit omzet naar een stroom random getallen. Er zijn vele commerciële apparaten te koop die random getallen produceren. Er zijn linux distributies de random getallen produceren aan de hand van muisbewegingen en netwerk activiteit. Uit een artikel [JSHJ98] blijkt dat de toegangstijd van harde schijven een erg goede bron is om random getallen te genereren. Het voordeel hier van is dat geen extra hardware nodig is. De pseudo random generator is een algoritme, wat random getallen lijkt te geven, maar wel deterministisch is. Met dezelfde input zal het algoritme hetzelfde resultaat opleveren. In het systeem in sectie 11.3 word voor het produceren van random getallen twee commerciele generatoren gebruikt. Voor de veilligheid, voor als een generator kapot gaat, worden de getallen met elkaar ge-xored. Voor de veilligheid wordt ook niet maar één pseudo random algoritme gebruikt maar meerdere.

11.5

Samenvatting

In loterijen gaat veel geld om, en loterijen en de consument zijn zeer gespitst op de veilligheid van loterijen. Aan loterijen kan je eisen stellen, welke eigenschappen een loterij dient te hebben. Een in gebruik zijnde elektronische nationale loterij is tot in detail uitgelegd. Verscheidende cryptografische technieken zijn nodig, om een loterij goed te implementeren. Nog veel literatuur over elekronische nationale loterijen is er nog niet, maar gezien de bedragen die bespaart kunnen worden, zullen steeds meer loterijen overstappen. De nadruk heeft op pokeren en aanverwante spellen gelegen, maar zodra meer loterijen elektronisch worden, zal ook de vraag naar onderzoek toenemen.

110

Loterijen

Hoofdstuk 12 Digitale identificatie Door R.A. van den Beukel

Dit hoofdstuk behandeld het identificeren van personen op internet. Er wordt beschreven waarom het identificeren in de digitale wereld specifieke aandacht behoeft en er worden twee voorbeelden van digitale identificatie behandeld. Mensen hebben er totaal geen problemen mee om anderen te herkennen. Er zijn zelfs onderdelen in onze hersenen die speciaal uitgerust zijn voor deze taak en in onderzoek zijn aanwijzingen gevonden dat een baby in staat is om het gezicht van z’n moeder te herkennen binnen een week. We herkennen de mensen om ons heen aan de manier waarop ze eruit zien, of aan hun stem. We kunnen dus bepalen wie iemand is door onze zintuigen te gebruiken en de informatie die we daardoor ontvangen te vergelijken met wat we van iemand weten. (Bijvoorbeeld hoe hij of zij er uit ziet.) Het bepalen van iemand wie iemand is noemen we identificatie, oftewel het vaststellen de identiteit van iemand. In de maatschappij is het belangrijk om te kunnen bepalen wie degene tegenover ons is. Denk bijvoorbeeld aan een bibliotheek, waar de bibliothecaris in staat moet zijn om te bepalen wie ik ben zodat ze in het computersysteem van de bibliotheek kan controleren of ik wel boeken mag lenen en of er niet nog uitstaande boetes zijn. Een dergelijke identificatie verloopt vaak met behulp van een identificatiemiddel zoals een paspoort of een speciaal hulpmiddel dat door een instantie uitgegeven wordt. In het geval van de bibliotheek zal sprake zijn van het laatste, namelijk een bibliotheekpas. Een soortgelijk systeem wordt gebruikt bij banken, overheden, ziekenhuizen, enzovoorts... Dit systeem heeft jarenlang prima gefunctioneerd. Want, zoals Prins en De Vries aangeven in hun paper [PV03]: “Meerdere stelsels van regels, instituties en ondersteunende informatiesystemen creëerden betrouwbare identificatiemiddelen, waarmee de koppeling tussen informatie en identiteit vrijwel probleemloos gemaakt kon worden.” Maar met de invoering van computers in vrijwel alle aspecten van onze maatschappij is er een probleem ontstaan. Bedrijven bijvoorbeeld die hun diensten of producten op het internet aanbieden moeten in staat zijn om de afnemer te identificeren alvorens ze de koop kunnen sluiten. Dit is noodzakelijk omdat een bedrijf moet weten bij wie ze verhaal kunnen halen als de rekening niet betaald wordt. 111

112

Digitale identificatie

Identificatie over het internet, ofwel digitale identificatie, brengt echter de nodige complicaties met zich mee. Het is voor een mens al lastig om iemand over op internet de identificeren omdat we er niet op kunnen vertrouwen dat de aangeleverde informatie correct is. Onze eigen ogen vertrouwen we wel, maar hoe kunnen we zeker weten dat als we via een webcam iemand te zien krijgen dat dit ook degene is met wie we communiceren? Veelal echter willen bedrijven dat een computersysteem de identificatie uitvoert en dat is waar de ellende begint. Digitale controle van analoge gegevens levert nog behoorlijk wat problemen op en is bovendien relatief eenvoudig om de tuin te leiden. Het soort analoge gegevens waar we aan zouden kunnen denken zijn irisscans, vingerafdrukken, videosignalen of stemgeluiden. Hoewel deze gegevens digitaal verstuurd en gemeten kunnen worden zijn ze analoog van aard met alle daarbij behorende nadelen zoals ruis en invloeden vanuit de omgeving. En zelfs als de controle op deze gegevens feilloos zou zijn blijven we met het probleem zitten dat we moeilijk kunnen controleren of de aangeleverde gegevens overeen komen met die van de persoon waarmee we communiceren. Een eenvoudig voorbeeld. Stel dat gebruikers zich moeten identificeren met een vingerafdruklezer. Het is al lastig om een apparaat te maken dat niet te gemakkelijk om de tuin te leiden is door bijvoorbeeld een printje van de vingerafdruk bij de lezer te houden. Maar als dat al lukt dan moeten we eigenlijk ook controleren of er nog wel bloed door de vinger stroomt, want hij zou afgehakt kunnen zijn. En we moeten verifiëren dat als de eigenaar en de vinger nog met elkaar verbonden zijn, dat deze dan niet in de loop van een pistool zit te turen. Dit laatste probleem is overigens lastig op te lossen, ongeacht de wijze van identificatie die gebruikt wordt. Het is dus noodzakelijk dat een identificatieschema verzonnen wordt dat toegespitst is op de uitvoering ervan door computers. Kortom, een schema dat gebruik maakt van gegevens die door een computer eenvoudig te controleren zijn. Ook willen we dat het schema afdwingt dat de persoon met wie we communiceren de gegevens aanleverd op basis waarvan we de identificatie doen. In de rest van dit paper zullen er twee voorbeelden gegeven worden van identificatieschema’s die voor dit doel gebruikt worden. Daarna zal ge¨ıllustreerd worden wat voor gevaar er schuilt in de willekeur waarmee organisaties hun eigen identificatieschema’s ontwerpen. Maar om te beginnen volgen een aantal definities.

12.1

Definities

12.1.1

Digitale identiteit

De definitie Kim Cameron, Identiteits Architect bij Microsoft Corporation, zal gebruikt worden. Hij presenteert deze definitie in zijn paper “The laws of identity” [Cam05]. Op dit paper zal later nog terug gekomen worden. Cameron definieert digitale identiteit als volgt: “a set of claims made by one digital subject about itself or another digital subject.” Vrij vertaald is een digitale identiteit dus een verzameling beweringen van een digitaal object over zichzelf of over een ander digitaal object. Hieronder volgen twee voorbeelden

12.1 Definities

113

van beweringen die in een digitale identiteit zouden kunnen zitten: Mijn studentennummer is 0205413 (Een bewering van een object over zichzelf) Stel dat Pieter het master programma aan de universiteit afgerond zou hebben en dat hij zou willen dat zijn diploma per post verstuurd wordt. Hij zou dan misschien op de website van de faculteit aan kunnen geven dat hij dit wil, door zijn studentennummer op te geven en het adres waar hij het diploma wil ontvangen. Door zijn studentnummer in te geven uit hij bovenstaande bewering. Voor de persoon (of computer) die deze aanvraag moet behandelen is het natuurlijk onzeker of Pieter wel daadwerkelijk degene is die dit studentennummer heeft. Dit zou gecontroleerd kunnen worden door nog wat meer informatie te vragen, die alleen de echte student met dit nummer kan weten 1 . Als de faculteit overtuigd is van de waarheid van de bewering kan deze de bewering in haar verzameling beweringen over de aanvrager opnemen (“Het studentennummer van de persoon die de aanvraag deed is 0205413”) en daar conclusies aan verbinden. Gebruiker pino123 kent sleutel k123 (Een bewering van een object over een ander object) Een server die deze bewering opgenomen heeft in de verzameling beweringen die bij de digitale identiteit van gebruiker pino123 hoort geeft hiermee aan dat iemand die beweert gebruiker pino123 te zijn, maar die niet kan bewijzen dat hij of zij k123 kent ook niet gebruiker pino123 kan zijn. De term digitaal object in de definitie verdient nog enige uitleg. Hiermee wordt een digitale representatie van een persoon of ding bedoeld. Er zijn al enkele voorbeelden de revue gepasseerd; een webserver, personen die op internet surfen, maar bijvoorbeeld ook groepen personen die ergens toegang tot hebben. Uit deze definitie volgt direct dat identiteit een begrip is dat sterk afhankelijk is van de context waarin ernaar gekeken wordt. Een voorbeeld hiervan wordt uitgewerkt in casus 12.1. 12.1.2

Controle aspecten

Stel dat Alice zichzelf tegenover Bob wil identificeren, dan zijn er drie aspecten waar Bob op kan controleren. Hij kan Alice identificeren op basis van wat ze weet, heeft of is. Een korte uitleg volgt: Wat ze weet Dit is een veel gebruikte methode, waarbij Bob er vanuit gaat dat Alice iets weet wat niemand anders weet. Bijvoorbeeld een wachtwoord. Wat ze heeft Bij deze methode gaat Bob uit van iets dat alleen Alice heeft, bijvoorbeeld de bankpas van haar bankrekening of een apparaat dat bepaalde getallen genereerd. Wat ze is In dit geval gaat Bob uit van bepaalde kenmerken die Alice heeft omdat ze Alice is. Bijvoorbeeld een bepaalde vingerafdruk of specifiek DNA-profiel. 1

Aangezien er geen beperkingen zijn aan wat iemand wel en niet kan weten is deze vorm van controle nogal zwak, maar hij wordt toch alom gebruikt.

114


Kader 12.1: Voorbeeld van de context afhankelijkheid van identiteit De figuur hiernaast toont drie verschillende contexten van waaruit naar de identiteit van een persoon gekeken kan worden. Laten we deze persoon Theo noemen. De figuur laat zien dat de professionele identiteit beweringen bevat over de functie die Theo uit oefent en over zijn salaris. Maar bovendien ook over zijn naam, adres en of Theo op een bepaald moment ziek is. Deze gegevens worden bij gehouden in het computersysteem van het bedrijf waar Theo werkt en vormen dus zijn professionele identiteit. De huisarts van Theo houdt ook de nodige informatie over hem bij. Zoals de figuur laat zien zit hier een deel overlap in, namelijk zijn naam, adres en medische toestand. Maar de huisarts kan ook beweringen doen over het laatste bezoek van Theo of de medische problemen die Theo in het verleden doorstaan heeft. Zijn werkgever kan hier geen beweringen over doen, net zoals de dokter geen beweringen kan doen over het salaris dat Theo bij zijn werkgever ontvangt. Door een van bovengenoemde methoden te kiezen wordt niet per se een goed identificatie systeem verkregen. Alle drie de methoden hebben namelijk zo hun voor- en nadelen. Een combinatie van de methoden biedt meestal de sterkste oplossing. Het gebruik van de laatste methode vraagt hier enige extra aandacht, omdat daar verder niet op terug gekomen zal worden. Deze methode heeft veel potentie omdat er niets geheim gehouden hoeft te worden. Maar er zijn nog een aantal praktische problemen. Zo gelden de problemen die in de introductie al aangegeven werden hierbij, namelijk dat het lastig is om zekerheid te krijgen van de authenticiteit van de ontvangen gegevens en de lastigheid die samenhang met het controleren van gegevens met een analoge basis. Daarnaast is er nog de discussie over de rechtmatigheid van het opslaan van dergelijke gegevens voor gebruik bij identificatie. Hierover is meer informatie te vinden in het paper van Cavoukian [Cav99].

12.2

Internetbankieren

De meeste banken leveren tegenwoordig internetbankieren aan hun klanten. De gebruiker kan met deze dienst zijn rekeninginformatie bekijken, geld overmaken, rekeningen betalen, enzovoorts. Omdat de dienst dus de mogelijkheid biedt om toegang tot het geld van de klanten van de bank te verkrijgen is het van groot belang dat alleen de eigenaar de rekening gebruik kan maken van de dienst. Het is dus ook erg belangrijk om de bezoekers van de webserver van de bank juist te identificeren. Hoewel dit niet altijd zo geweest is gebruiken de meeste banken tegenwoordig min of

12.2 Internetbankieren

115

meer hetzelfde systeem. Hierbij wordt de verbinding tussen de cliënt en de bank beveiligd met een SSL verbinding en er wordt gebruik gemaakt van een van de apparaten uit de VASCO DigiPass (DP) familie. Op beide systemen zal hierna wat dieper in gegaan worden. Voordat er verder gegaan wordt is het van belang om op te merken dat het erg problematisch is om informatie over de werkwijze te verkrijgen die de banken hanteren bij het identificeren van de mensen die in willen loggen op het internetbankierensysteem. De banken zijn blijkbaar niet overtuigd van de correctheid van het principe van Kerckhoffs2 . Dit principe zegt dat de veiligheid van een cryptografisch systeem alleen af mag hangen van de geheime sleutel en niet van de onbekendheid van de werking van het systeem. 12.2.1

SSL

Zoals al aangegeven werd maken de banken gebruik van SSL om de verbinding tussen de client en de server te beveiligen. SSL is een afkorting voor Secure Socket Layer en de taak van SSL is om bovenop de netwerk laag een beveiligingslaag te plaatsen. Hierdoor wordt voorkomen dat buitenstaanders de communicatie af kunnen luisteren. Bij communicatie via SSL maakt de client verbinding met de server en gedurende de eerste paar berichten wordt een sessiesleutel overeengekomen die gedurende de rest van de communicatie gebruikt wordt om de berichten te versleutelen en te ontsleutelen. De fase waarin deze sleutel bepaald wordt is zodanig ontworpen dat alleen de partijen die deelnemen aan de conversatie achteraf over de sleutel beschikken. Het voert voor nu te ver om de details van het SSL protocol te behandelen, maar de specificatie van SSL 3.0 uit 1996 kan op de website van Netscape terug gevonden worden3 . Door SSL wordt weliswaar de communicatie tussen de beide partijen beveiligd, maar er is nog geen enkele zekerheid over de identiteit van beiden. De identiteit van de server wordt vaak vastgelegd door gebruik te maken van een certificaat. Een dergelijk certificaat wordt uitgegeven door een Certificerings Autoriteit (CA), waarvan we aannemen dat deze te vertrouwen is. De CA controleert de identiteit van een aanvrager voordat het certificaat afgegeven wordt. Als het certificaat dan afgegeven wordt, dan wordt dit gekoppeld aan de zogenaamde publieke sleutel van de aanvrager. Deze publieke sleutel wordt gebruikt in de fase waarin de sessiesleutel bepaald wordt en de cliënt kan dus op basis van het vertrouwen in de CA en het certificaat dat hoort bij de gebruikte publieke sleutel de identiteit van de server vaststellen. Het vast stellen van de identiteit van de cliënt ligt een stuk lastiger, omdat cliënten in het algemeen niet over een certificaat beschikken. Dit is ook niet heel vreemd als we kijken naar de kosten van een dergelijke certificaat bij VeriSign. Deze CA rekent voor het afgeven van een certificaat een luttele $ 400,- per jaar. De banken gebruiken voor het identificeren van de cliënt de VASCO DigiPass. 2

Kerkhoffs publiceerde dit principe, samen met vijf anderen, in zijn paper ‘La cryptographie militaire’ in 1883. [Ker83] 3 De SSL 3.0 specificatie is te vinden op http://wp.netscape.com/eng/ssl3/

116


Figuur 12.2: VASCO DigiPass Pro 800

12.2.2

VASCO DigiPass

De ABN AMRO bank en de Rabobank gebruiken de VASCO DigiPass. De Rabobank gebruikt de DigiPass 800 om precies te zijn, welke getoond wordt in figuur 12.2). Bij ING Luxemburg wordt gebruik gemaakt van de DigiPass Go3. Omdat deze banken en een aantal andere financiële instellingen de DP gebruiken zal wat verder ingegaan worden op de werking ervan. Deze beschrijving is gebaseerd op een paper van de producent van het apparaat VASCO [VAS03] en kan gevonden worden op haar website4 . De DP creëert een wachtwoord voor iedere keer dat de gebruiker in wil loggen op de website van de bank. Omdat dit wachtwoord iedere keer anders is wordt het een OneTime Password (OTP) genoemd. Het OTP wordt door de DP uitgerekend door gebruik te maken van de PIN-code van de gebruiker, enkele gegevens van de chip op de bankpas en enkele interne gegevens. Deze input wordt met behulp van het (3-)DES algoritme door elkaar geklutst tot een OTP. Dit is weergegeven in figuur 12.3. De interne gegevens die de DP gebruikt kunnen onder andere de waarde van een real-time klok zijn of de waarde van een teller die iedere keer dat een OTP aangemaakt wordt verhoogd wordt. Het is echter helaas niet duidelijk welke waarden precies gebruikt worden en op welke manier. Doordat DES gebruikt wordt kunnen we afleiden dat de sleutel die bij de creatie van het OTP gebruikt wordt ook op de server aanwezig moet zijn. DES is een zogenaamd 4

http://www.vasco.com

12.2 Internetbankieren

117

Figuur 12.3: De werking van de DigiPass

symmetrisch protocol, wat wil zeggen dat dezelfde sleutel gebruikt wordt voor het versleutelen en het ontsleutelen van de data. Ik vermoed dat de PIN-code van de gebruiker (of een afleiding daarvan) hiertoe dient, maar daar is eigenlijk weinig over te zeggen. Veel van de banken maken gebruik van een challenge-response protocol. In dit geval plaatst de bank voordat het OTP gegenereerd wordt een code op zijn website. Dit is de challenge. Deze challenge-code wordt door de DP gevraagd bij het uitrekenen van het OTP en meegenomen in de berekening met DES. Het OTP is de response code. Bij de Rabobank wordt dit protocol bijvoorbeeld gebruikt als de gebruiker heeft aangegeven dat hij de klaargezette betalingen uit wil voeren. De bank toont dan een scherm met de betalingen die gedaan zullen worden, een 8-cijferige challenge code en een invoerveld voor de response. De gebruiker zet nu zijn DP aan, steekt de bankpas in de DP en voert zijn PIN-code in. Hierna zal de DP vragen om de 1e invoer, dit is de challenge die op de pagina getoond wordt. Als op OK gedrukt wordt op de DP wordt gevraagd om de 2e invoer, maar dat kan genegeerd worden. Er moet nu nogmaals op OK gedrukt worden en vervolgens verschijnt de response in het scherm van de DP. 12.2.3

Veiligheid van internetbankieren

De banken hebben ervoor gekozen om het inloggen op hun internetbankieren websites te koppelen aan zowel wat de cliënt weet en wat hij bezit. Het OTP wordt namelijk bepaald op basis van de gegevens van de bankpas van de gebruiker (wat hij bezit) en de bijbehorende PIN-code (wat hij weet). Ook het genereren van een OTP biedt extra bescherming voor de identiteit van de gebruiker omdat een eenmaal afgekeken wachtwoord niet nogmaals gebruikt kan worden.

118


12.3

Elektronische Overheid

Overheden hebben het vermogen op individuen te identificeren aan de kern van hun bestaansrecht staan. Dit is nooit echt een probleem geweest, maar met de komst van de digitale wereld is er een ruimte ontstaan waarvan de overheden in onder andere Amerika en Nederland huiverig lijken te zijn om deze op te vullen [Win03]. Zoals in de inleiding op pagina 111 al aangegeven werd het proces van identificatie — dat voor de invoering van de computers soepel verliep— een stuk ingewikkelder geworden na de invoering van computersystemen. Toch is het voor de taken die een overheid uit moet voeren van groot belang dat ze in staat is om haar burgers te identificeren. Hierbij kan gedacht worden aan het verlenen van toestemming voor bepaalde zaken aan bepaalde personen, het verschaffen van voorzieningen aan hulpbehoevenden of het inzamelen van informatie voor bijvoorbeeld de belastingdienst. Omdat de overheid haar diensten in deze tijd ook digitaal aan wil gaan bieden, hetgeen interessant is omdat daardoor kostbare communicatie en menselijke interventie terug gedrongen kunnen worden, heeft ze getracht een digitaal identificatiesysteem op te zetten onder de naam DigiD. 12.3.1

DigiD

Al ruim voordat de overheid haar zinnen gezet had op het aanbieden van het diensten in de digitale ruimte werd een groot deel van het werk van de overheid digitaal gedaan. Zo houdt de belastingdienst van alle burgers gegevens bij die gekoppeld zijn aan het SOFI-nummer5 . Het gebruik van het SOFI-nummer is bij wet beperkt tot overheidsinstanties en de overheid heeft daarom het Burgerservicenummer (BSN) bedacht. Dit nummer is identiek aan het SOFI-nummer, maar heeft minder beperkingen. Daardoor kan het bijvoorbeeld ook bij banken als identificatie nummer gebruikt worden. Een andere belangrijke overheidsinstelling is de GBA6 . Deze houdt informatie bij over de adresgegevens van inwonenden van de gemeente. Deze gegevens zijn gekoppeld aan een zogenaamd A-nummer7 . Het DigiD is een combinatie van een gebruikersnaam en wachtwoord welke door de burger zelf gekozen worden. Aan de hand van de ingevoerde gegevens worden de adresgegevens van de burger opgezocht bij de GBA en er wordt een activeringscode voor het DigiD account naar dit adres gestuurd. De burger kan zijn account activeren door deze code samen met de gekozen gebruikersnaam en wachtwoord in te geven op de website van DigiD. De verbinding tussen de cliënt en de website van DigiD wordt met SSL beveiligd, op dezelfde manier als dat de banken dit doen. Meer hierover in sectie 12.2.1. Een voorbeeld van het gebruik van DigiD zal besproken worden aan de hand van figuur 12.4. Stel dat een burger een aanvraag bij de gemeente wil doen voor een rolstoel. Normaal gesproken zou de burger hiervoor naar het ZorgLoket moeten, maar sinds de 5

SOciaal-FIscaal nummer Gemeentelijke Basis Administratie 7 Administratie-nummer 6

12.3 Elektronische Overheid

119

Figuur 12.4: Gebruik van het DigiD

invoering van DigiD zijn er ook gemeenten die een elektronisch zorgloket aanbieden. De burger surft naar de website van de gemeente een selecteert uit het overzicht van aangeboden voorzieningen de rolstoel die hij of zij nodig heeft. Om de aanvraag daadwerkelijk te plaatsten geeft de burger zijn DigiD gebruikersnaam en wachtwoord in, deze worden door het systeem van de gemeente gecontroleerd bij de landelijke DigiD server. Als de gegevens correct zijn wordt ofwel het BSN terug gegeven ofwel het A-nummer. Omdat het gebruik van het A-nummer beperkt is tot de GBA zal in dit geval het BSN terug gegeven worden. Hiermee kan de gemeent vervolgens in haar eigen databank opzoeken en de bekende gegevens alvast invullen voor deze burger. De burger vult vervolgens het formulier verder in en verzend dit -digitaal- naar de gemeente. Hierna zal de gemeente de burger een bevestiging van de aanvraag sturen en de aanvraag beoordelen, maar daar zal verder niet op ingegaan worden, omdat dat voor dit paper niet van belang is. In het zonet gegeven voorbeeld wordt gebruik gemaakt van de zogenaamde basis veiligheid die DigiD biedt. Er bestaan nog 2 hogere niveau’s, waarvan de eerste inmiddels ook ge¨ımplementeerd is. Om hiervan gebruik te kunnen maken moet de burger bij zijn DigiD gegevens ook zijn mobiele telefoonnummer opgeven. Als de burger dan probeert om in te loggen bij DigiD met dit tweede beveiligingsniveau, dan zal de DigiD server na het controleren van de gebruikersnaam en het wachtwoord een SMS-bericht naar de telefoon van de burger sturen met daarin een sessiecode. Deze sessiecode moet de burger

120


vervolgens ingeven om verder in te kunnen loggen. 12.3.2

Veiligheid van DigiD

De overheid begeeft zich mijnsinzien op glad ijs met de invoering van het DigiD in z’n huidige vorm. Het beveiligen van gegevens middels een zelf gekozen gebruikersnaam en wachtwoord is vragen om problemen. Ten eerste omdat gebruikers de eigenschap hebben om voor hun wachtwoord vrijwel altijd een geboorte datum of naam van een familielid te nemen en ten tweede omdat deze gegevens statisch zijn. Als een kwaadwillende dus eenmaal mijn gebruikersnaam en wachtwoord achterhaald heeft dan kan hij in het vervolg zo bij mijn gegevens. (Tot het wachtwoord gewijzigd wordt, maar veel gebruikers doen dit zelden tot nooit.) De overheid heeft zoals gezegd nog twee hogere niveau’s van de beveiliging klaar staan, maar de invoering van het systeem met het basisniveau is onverstandig. Zo bleek ook uit kritiek van het Genootschap van Informatie Beveiligers8 in april 2006. Hierna is de overheid met het tweede niveau van beveiliging gaan testen. Het tweede niveau van beveiliging biedt dit op basis wat de burger weet (DigiD gegevens) en wat hij heeft (mobiele telefoon). Ik denk dat dit niveau wel volstaat om voldoende zekerheid te bieden voor het uitvoer van bepaalde taken van de overheid. Toch denk ik dat voor bepaalde taken het geen verkeerd idee is om de burger toch te verplichten zich te melden op het gemeentehuis. Zoals bijvoorbeeld het verlengen van een paspoort. Als dat mogelijk zou worden via DigiD, dan slaat de overheid denk ik wel een beetje door.

12.4

Een gevaarlijke chaos

In de voorgaande twee secties zijn voorbeelden besproken van oplossingen om digitale identificatie toe te passen. Dit zijn voorbeelden van tamelijk sterke systemen. Bedrijven bijvoorbeeld die hun producten op internet aanbieden gebruiken een zelf gekozen gebruikersnaam met dito wachtwoord waarmee de ingelogde gebruiker producten kan bestellen. Doordat veel bedrijven bij het ontwikkelen van de website waarop de diensten of producten aangeboden ook zelf ter plekke een manier verzinnen om de gebruikers in te laten loggen (en dus te identificeren), is het internet een chaos geworden van dit soort oplossingen. Een dergelijke ter plekke verzonnen oplossing wordt ook wel een ad-hoc oplossing genoemd. De internet gebruiker is niet anders gewend dan deze chaos en vindt het dan ook volstrekt normaal om zijn of haar persoonlijke gegevens in iedere willekeurig invoerveld in te geven waar om deze gegevens gevraagd wordt. Hierdoor ontstaat de eenvoudige mogelijkheid om naar gebruikersgegevens te gaan vissen (phishing). Zie voor meer informatie over phishing casus 12.5 Daarnaast is het deze chaos voor een gebruiker bijna onmogelijk om bij te houden welke gegevens op welke plaats opgeslagen zijn, laat staan om te kunnen controleren 8

Het GvIB is te vinden op http://www.gvib.nl/

12.4 Een gevaarlijke chaos

121

Kader 12.5: Phishing Bij het vissen naar gebruikersgegevens wordt een bepaalde webpagina zodanig nagemaakt dat het voor de gebruiker lastig is om deze van de echte te onderscheiden. Vervolgens wordt de internet gebruiker naar deze pagina toe geleid, bijvoorbeeld via een e-mailtje of een andere internetpagina. Op de pagina geeft de gebruiker zijn inloggegevens in en de webpagina laat een foutmelding zien dat de pagina tijdelijk uit de lucht is. Maar ondertussen heeft hij wel de logingegevens opgeslagen. Hierna kan op de originele pagina ingelogd worden en kan de identiteit van de misleide gebruiker worden gebruikt om van diensten gebruik te maken of om producten te bestellen. wat er mee gebeurt. Dit probleem is gesignaleerd door Kim Cameron —eerder genoemd bij de definitie van een digitale identiteit (sectie 12.1.1). Cameron heeft zeven wetten bedacht waaraan een identiteitssysteem zou moeten voldoen om de gebruikers meer invloed en veiligheid te geven met betrekking tot hun digitale identiteiten. 12.4.1

De zeven wetten van identiteit

De volgende zeven wetten zijn door Cameron beschreven in zijn paper “The laws of identity” [Cam05]. Er zal nu slechts een korte beschrijving volgen, voor meer informatie wordt verwezen naar het paper. Toestemming en beheer van de gebruiker Gebruikers moeten zelf het beheer over hun identiteiten kunnen voeren. Het systeem moet ze daarbij ondersteunen. Minimale ontsluiting voor beperkt gebruik Alleen die informatie die strikt noodzakelijk is voor het gebruik in een bepaalde situatie moet prijsgegeven worden. Meerketennummers moeten voorkomen worden. (Een voorbeeld van een meerketennummer is het BSN, dit is een nummer dat bij meerder instanties gebruikt wordt) Gerechtigde partijen Allen partijen die betrokken zijn in de context waarin de identificatie plaats vindt, hebben het recht om deze informatie te bekijken. Ook moet de gebruiker erop kunnen vertrouwen dat een zelf juist ge¨ıdentificeerd wordt. De gerichtheid van identiteit Het systeem moet zowel identiteiten ondersteunen die door iedereen opgevraagd kunnen worden als identiteiten die alleen richting een bepaalde organisatie getoond mag worden. Veelvoud van operatoren en technologie¨ en Het moet mogelijk zijn om binnen het identiteitssysteem meerdere technologieën te gebruiken. Kortom, het systeem moet een basis definiëren waarbinnen naar wens nieuwe technologieën toegepast kunnen worden. Cameron geeft als voorbeeld HTML, dat weliswaar een formaat beschrijft, maar niet de inhoud.

122


Menselijke integratie Het systeem moet de gebruiker zelf integreren, in plaats van alleen zijn computer systeem. Hiermee bedoeld Cameron onder andere dat het systeem phishing tegen moet gaan. Consistente ervaring binnen meerdere contexten Hoewel een gebruiker moet kunnen schakelen van identiteit A naar identiteit B, moet de manier waarop het systeem werkt voor hem hetzelfde blijven.

Samenvatting en conclusies In dit paper is beschreven hoe het invoeren van computers in het proces van de identificatie voor de nodige uitdagingen gezorgd heeft. Er zijn twee voorbeelden van gebruikte oplossingen beschreven, namelijk de oplossing die bij internetbankieren gebruikt wordt en de oplossing die de Nederlandse overheid gekozen heeft voor het identificeren van haar burgers. Er is getoond dat de situatie die ontstaan is na de invoering van computers in het identificatieproces op internet gezorgd heeft voor een wir-war van oplossingen die de gebruiker in de kou laten. Kim Cameron heeft een aantal wetten opgesteld waar toekomstige systemen zich aan zouden moeten conformeren opdat het voor de gebruiker een veiliger internet wordt.

Hoofdstuk 13 Hardeschijf versleuteling Door Martin Warmer

Bijna alle belangrijke gegevens worden tijdens hun pad door de computer op de harde schijf weggeschreven. Dit kan gebeuren als iemand expliciet de gegevens naar een bestand wegschrijft. Maar het kan ook gebeuren omdat een gedeelte van het RAMgeheugen naar een swapfile wordt weggeschreven. Of ze worden weggeschreven als tijdelijke bestanden voor gebruik bij een ”reddingsoperatie”na een crash. (Ontzettend handig als de computer onverhoopt crasht.) Bij al deze mogelijkheden is het belangrijk om ervoor te zorgen dat de gegevens niet in klaretekst-vorm op de hardeschijf komen te staan. Daarom gaan we in dit hoofdstuk kijken naar de verschillende mogelijkheden om een hardeschijf te versleutelen.

13.1

Bestands versleuteling

Bestands versleuteling is de makkelijkste manier om gegevens versleuteld op te slaan. Hierbij zeg je tegen de software die het bestand bewerkt dat het versleuteld moet worden opgeslagen. Deze mogelijkheid zit bijvoorbeeld standaard in software als Microsoft Office of een database pakket. Dit is efficient omdat alleen de belangrijke gegevens versleuteld worden. Ook is het heel makkelijk om de bestanden veilig te e-mailen of op een server te zetten. Maar de gegevens worden niet alleen in het versleutelde bestand opgeslagen op een hardeschijf. Zo gebruiken een hoop programma’s tijdelijke bestanden om (een gedeelte van) de gegevens in op te slaan. Voorbeelden hiervan zijn opgeslagen undo-operaties of speciale checkpoints om een bestand te reconstrueren na een crash. Besturingssystemen gebruiken zogenoemde swapbestanden waarin ze stukken van het ram-geheugen tijdelijk parkeren als er geheugen tekort is. Dit gebeurt allemaal zonder dat de applicatie met de belangrijke gegevens in zijn geheugen het door heeft. Dus kan de applicatie zich hier ook niet tegen beveiligen. 123

124

Hardeschijf versleuteling

13.2

Een eerste oplossing

Vanwege de problemen met bestands versleuteling willen we de hele hardeschijf versleutelen. Dit betekent dat alle lees- en schrijfoperaties op de schijf (transparant) worden versleuteld. Hierdoor kan iemand zonder de sleutel de inhoud van de hardeschijf niet lezen. Deze lees- en schrijfoperaties gebeuren per sector. Deze eenheid is meestal 512 bits, maar kan van hardeschijf tot hardeschijf verschillen. Omdat dit de standaardeenheid van de hardeschijf is, lijkt het de meest logische keuze om de hardeschijf per sector te versleutelen. Voor de versleuteling gebruiken we AES, wat een blokgrootte van 128 bits heeft. Dus elke sector wordt in stukjes van 128 bits ingedeeld. In het geval van een 512 bits sector hebben we dus 4 AES blokken van 128 bits. We gebruiken AES in de standaard ECB (electronic code book) modus. Dit betekent dat elke 128 bits apart worden versleuteld zonder afhankelijk te zijn van de rest. Door deze versleuteling wordt elk 128 bits blok goed door elkaar gehusseld. Waardoor het zonder sleutel moeilijk wordt om de inhoud van zo’n blok te achterhalen. Maar zelfs al weten we de inhoud niet, we kunnen precies zijn wanneer twee blokken dezelfde inhoud hebben. In dat geval zien ze er versleuteld namelijk ook hetzelfde uit. Dit willen we voorkomen want hierdoor kan een aanvaller veel te veel informatie over de inhoud van de hardeschijf achterhalen. Een tweede probleem met onze aanpak is dat hij alleen werkt als de sectorgrootte een meervoud van 128 bits is. Zo niet, dan kunnen we de versleuteling niet per sector doen. Waardoor de versleuteling niet meer transparant is voor alle applicaties. Databases gaan er bijvoorbeeld vanuit dat het schrijven naar een sector, de omliggende sectoren niet kan veranderen. Hierdoor weet een database dat als de stroom uitvalt, de gegevens nog in goede staat op de harde schijf staan. De oplossing voor dit probleem wordt gegeven door Ciphertext Stealing (CTS). Deze modus zorgt ervoor dat alle sectorgroottes van 128 bits en groter worden ondersteund. Het idee achter Ciphertext Stealing is om voor het laatste blok van de klaretekst een gedeelte van de cijfertekst te stelen. Hierdoor wordt het laatste blok tot 128 bits aangevuld en hoeven de gestolen cijfertekst bits niet apart opgeslagen te worden. De overige blokken (alle behalve de laatste twee) worden gewoon op de normale manier opgeslagen. Hieronder staat de werking in formule vorm weergegeven. Hierin is P0 het een na laatste blok van de klaretekst en P1 het laatste. De lengte van P1 is n en de functies head(x,y) en tail(x,y) pakken respectievelijk de eerste en de laatste y bits uit x. De functie E is de versleutelfunctie en || is de concatenatie operatie. • T = E(P0 ) • C0 = E(P1 ||tail(T, 128 − n)) • C1 = Head(T, n)

13.3 Getweakte versleuteling

13.3

125

Getweakte versleuteling

Om te voorkomen dat dezelfde klaretekst ook dezelfde cijfertekst oplevert hebben Liskov, Rivest en Wagner[LR] getweakte versleuteling bedacht. Hierbij wordt het versleutelingsalgoritme uitgebreid met een tweak variabele. Door deze variabele te veranderen kunnen we een familie van verschillende algoritmes genereren. De functie Ek (P ) wordt dus uitgebreid naar Ek (P, T ) waarbij T de tweak waarde is. Een belangrijke tweede eis aan het nieuwe algoritme is dat het veilig moet zijn zelfs al is de tweak waarde bekend bij de aanvaller. Dit betekent dat er voor de tweak waarde bijvoorbeeld het bloknummer kan worden gebruikt. Liskov, Rivest en Wagner hebben een getweakte variant van AES, genaamd LRWAES, voorgesteld. Deze modus maakt gebruik van berekeningen binnen een galoislichaam om een XOR-waarde uit te rekenen om AES te tweaken. Deze XOR-waarde wordt voor toepassing van AES geXORed met de klaretekst en het resultaat van de AES versleuteling wordt weer geXORed met deze waarde om het eindresultaat te verkrijgen. Voordat we nu verder gaan met de beschrijving van LRW-AES gaan we eerst wat basiskennis over galoislichamen opdoen. Definition 13.1 Een galoislichaam is een eindig lichaam over een macht van een priemgetal, pn . Waarbij elk element in het lichaam bestaat uit een polynoom van orde hoogstens n − 1 met coefficienten uit Zp in combinatie met een reductiepolynoom r van orde n. Zoals hierboven beschreven bestaat een galoislichaam uit polynomen. De coefficienten van deze polynomen komen uit Zp en de orde is n − 1 of lager. Deze polynomen kunnen volgens de normale regels worden opgeteld en vermenigvuldigt worden. Waarna ze om het lichaam eindig te houden moeten worden gereduceerd met de reductiepolynoom. Dit betekent dus dat de operaties ⊕ en ⊗ als volgt zijn gedefinieerd, a⊕b = a+b a⊗b = a+b

mod r mod r

(13.1) (13.2)

Dit betekent dat een galoislichaam met n = 1 zich hetzelfde gedraagt als Zp . Optelling kan ook gezien worden als alle coefficienten paarsgewijs optellen modulo p. Vermenigvuldiging is lastiger maar kan worden gedaan door de vermenigvuldiging uit te schrijven en de polynoom modulo r te nemen. Het voordeel van het gebruik van een lichaam is dat we de ”normale”rekenregels kunnen gebruiken. De geldende rekenregels zijn onder andere: Gesloten: Alle operaties leveren weer een resultaat in het lichaam op Associatief: (a ◦ b) ◦ c = a ◦ (b ◦ c) Commutatief: a ◦ b = b ◦ a Distributief: (a ⊕ b) ⊗ c = (a ⊗ c) ⊕ (b ⊗ c)

126


Figuur 13.1: LRW-AES diagram

In dit hoofdstuk zijn we voornamelijk geintresseerd in GF (2128 ). Elk coefficient uit GF (2128 ) kan namelijk als een bit worden gerepresenteerd, want Z2 bevat alleen de getallen 0 en 1. Om een polynoom te representeren uit GF (2128 ) hebben we dus 128 bits nodig. Dat is precies de blokgrootte van AES. Ook is het efficient om in binaire computers te implementeren. Zo kan een optelling (⊕) worden gedaan m.b.v. een XOR-operatie op elk paar bits.

13.4

LRW-AES

LRW-AES is een getweakte variant van AES met twee 128 bits sleutels, Key1 is de sleutel voor de AES versleuteling en Key2 is de sleutel voor het berekenen van de tweak T x. Voor de rest zijn gegeven de klaretekst P en de tweak invoer T . De manier om met LRW-AES te versleutelen is als volgt • T x = Key2 ⊗ T • C = T x ⊕ EKey1 (P ⊕ T x) We verkrijgen dus door vermenigvuldiging van Key2 en het bloknummer T de waarde waarmee de in- en uitvoer van de AES versleuteling moet worden geXORed. (Vergeet niet dat in GF (2128 ) optellen en XORen hetzelfde zijn.) Hierdoor wordt voor de versleuteling voor elk blok anders. Dit heeft als voordeel dat een aanvaller het niet meer kan zien wanneer twee verschillende sectoren dezelfde inhoud hebben. Ook maakt dit het, zonder bezit van de sleutels, onmogelijk om versleutelde blokken te verplaatsen op de hardeschijf. Dus een aanvaller die weet dat zijn salaris op sector x staat en het salaris op sector y kan zijn salaris niet verhogen door de inhoud van sector y naar sector x te kopieren.

13.5 XTS-AES

127

Maar ondanks deze mooie eigenschappen heeft LRW-AES ook problemen. De belangrijkste daarvan is dat het gevaarlijk is om Key2 naar de hardeschijf weg te schrijven. Dit is belangrijk omdat, zoals eerder besproken, willekeurige stukken geheugen tijdelijk naar een swapbestand op de hardeschijf kunnen worden weggeschreven. De aanval is mogelijk als Key2 precies op de grens van een blok wordt weggeschreven en het daarop volgende blok alleen nullen bevat. Om te laten zien hoe dit mogelijk is gebruiken we Cn als de versleutelde versie van Key2 en Cn+1 als blok met nullen dat daarop volgt. We kijken eerst naar hoe de versleutelde waardes Cn en Cn+1 worden berekend. Cn = (Key2 ⊗ n) ⊕ EKey1 (Key2 ⊕ (Key2 ⊗ n)) Cn = (Key2 ⊗ n) ⊕ EKey1 (Key2 ⊗ (n + 1)) Cn+1 = (Key2 ⊗ (n + 1)) ⊕ EKey1 (0 ⊕ (Key2 ⊗ (n + 1))) Cn+1 = (Key2 ⊗ (n + 1)) ⊕ EKey1 (Key2 ⊗ (n + 1))

We zien hier dat de invoer voor de AES versleuteling in beide gevallen hetzelfde is. Dit betekent dat de uitvoer ook hetzelfde moet zijn, ze gebruiken immers beide de sleutel Key1. Dit kunnen we gebruiken door Cn en Cn+1 te XORen, dan valt namelijk de uitvoer van AES tegen zichzelf weg. Waarna we met wat herschrijven, (Key2 ⊗ n) weg kunnen laten vallen en we Key2 kunnen achterhalen. Cn ⊕ Cn+1 = (Key2 ⊗ n) ⊕ EKey1 (Key2 ⊗ (n + 1)) ⊕ (Key2 ⊗ (n + 1)) ⊕ EKey1 (Key2 ⊗ (n + 1)) Cn ⊕ Cn+1 = (Key2 ⊗ n) ⊕ (Key2 ⊗ (n + 1)) Cn ⊕ Cn+1 = (Key2 ⊗ n) ⊕ (Key2 ⊗ n) ⊕ Key2 Cn ⊕ Cn+1 = Key2 We zien dus dat Key2 te achterhalen is als hij op de verkeerde manier naar de hardeschijf wordt weggeschreven. Dit willen we niet, de sleutels zijn namelijk het enige geheim in dit algoritme. Het lekken van de sleutels zorgt er dus voor dat de veiligheid van dit systeem (in de worst case) maar net iets beter is dan AES in ECB modus.

13.5

XTS-AES

Een getweakte variant van AES die als opvolger van LRW-AES kan worden gezien is XTS-AES. Dit is een variant van AES met een XEX tweak in combinatie met CTS (Ciphertext Stealing). Omdat CTS al beschreven is zal ik hier alleen een korte beschrijving van de XEX tweak geven. In XEX wordt AES twee keer gebruikt, een keer als versleutelfunctie en een keer als randomiserende functie. De verbetering ten op zichte van LRW is dat AES als randomiserende functie veel minder structuur heeft dan de LRW vermenigvuldiging. De structuur van XEX is weergegeven in figuur 13.3.

128


Kader 13.2: IEEE P1619 Het Institute of Electrical and Electronics Engineers (IEEE) is een organisatie die onder andere standaarden vastlegt voor de computer industrie. Een van de aankomende standaarden is IEEE P1619 waarin een standaard manier voor hardeschijf versleuteling wordt vastgelegd. Voor het opstellen van deze standaard is de Secure Information Storage WorkGroup (SISWG) verantwoordelijk. De eerste versies van de standaard waren gebaseerd op LRW-AES. Maar vanwege de problemen met opslag van Key2 op de hardeschijf is 30 augustus 2006 besloten om een alternatief te zoeken. Dit alternatief is op het moment van schrijven XTS-AES (XEX als tweak in combinatie met CTS) Het ziet ernaar uit dat dit ook de uiteindelijke standaard zal worden. De XEX-tweak gebruikt ook twee 128 bits sleutels, die net als bij LRW Key1 en Key2 heten. Maar de tweak invoer (het bloknummer) is in dit geval gesplitst over T1 en T2 . Het idee hierachter is dat een AES versleuteling vrij traag is en dat het in de praktijk niet nodig is om dit voor elk blok te doen. Daarom is het mogelijk om maar voor een op de n blokken een randomiserende AES versleuteling uit te voeren. De tweak waarde voor de n verschillende blokken worden dan gegenereerd door T2 van 0 t/m n − 1 te laten lopen. Hierdoor wordt een bijna n versnelling verkregen met een verwaarloosbaar kleine toevoeging van extra structuur die gebruikt kan worden om XEX aan te vallen. In de praktijk wordt dit gedaan door T1 het sector nummer te laten zijn en T2 binnen de sector te varieren. Op het moment heeft XTS-AES eigenlijk geen bekende zwakheden. Althans voor zover die met behulp van XEX voorkomen kunnen worden. Het blijft voor een aanvaller die tijdelijk toegang heeft nog steeds mogelijk om sectoren terug te zetten die hij eerder gelezen heeft. Stel bijvoorbeeld dat een wachtwoord dat hij kent op sector x staat. Nu is

Figuur 13.3: XTS-AES diagram


129

hij slim geweest en heeft thuis een kopie van sector x opgeslagen. Dan kan hij nadat het wachtwoord gewijzigd is, de inhoud van sector x vervangen door de kopie die hij thuis heeft liggen. Het is duidelijk dat we dat niet willen, maar zolang de hardeschijf in losse stukjes wordt versleuteld houd je dit probleem. In het geval van XTS-AES gaat het om blokken van 128 bits lang (mogelijk tot 255 bits in verband met CTS) Die kunnen groter gemaakt worden zodat misbruik maken moeilijker wordt maar een aanvaller kan altijd de volledige inhoud van de hardeschijf terug zetten.

Samenvatting en conclusies We hebben in dit hoofdstuk gekeken naar verschillende manieren om de data op een hardeschijf (transparant) te versleutelen. De conclusie is dat dit zeer goed mogelijk is, maar dat we niet tegen alle mogelijke aanvallen kunnen beveiligen. Ondanks dit kleine bezwaar is het voor laptop bezitters een goed idee om hardeschijf versleuteling te gebruiken. Jaarlijks worden er vele laptops gestolen en sommigen daarvan worden doorverkocht voor de gegevens op de hardeschijf. Dit is makkelijk te voorkomen door hardeschijf versleuteling toe te passen. Het lijkt mij dan ook slim om dit verplicht te stellen voor laptops waarop met zeer vertrouwelijke informatie, zoals bijvoorbeeld staatsof handelsgeheimen, wordt gewerkt. Maar voor de gemiddelde thuisgebruiker is het de extra complexiteit en dus kans op problemen meestal niet waard.

130


Hoofdstuk 14 Valkuilen bij kleine exponenten in RSA Door Jefrey Lijffijt

Dit artikel geeft een grondig overzicht van de ontwikkelingen op het gebied van het kraken van RSA. Eerst wordt een introductie gegeven op RSA en op het gebruik van kleine exponenten en het belang ervan. Ook definiëren we wat een aanval op RSA inhoudt. Vervolgens worden een aantal algemene problemen aangekaart, waar men rekening mee moet houden bij een implementatie van RSA. Halverwege wordt overgestapt op een veelgebruikte variant van RSA, met kleine exponenten, en worden de gevaren die daarbij komen kijken besproken tot aan de huidige stand van zaken die daarover bekend is.

14.1

Introductie in het kraken van RSA

Om even een notatie af te spreken van belangrijke variabelen geven schetsen we het RSA-algoritme: [RSA78a] Kies twee grote priemgetallen p en q. Bereken de publieke modulus m = p · q en het Eulergetal φ(m) = (p − 1) · (q − 1). Kies een e ∈ Z∗m Bereken d zodanig dat d · e ≡ 1 mod φ(m) De publieke informatie is nu (m, e). De geheime informatie is nu (m, d). Encryptie is gelijk aan y = xe mod m Decryptie is gelijk aan x = y d mod m Kanttekeningen die we hierbij kunnen plaatsen: Straks zullen we aantonen dat p en q het beste ongeveer even groot moeten worden gekozen (zie 14.5 en 14.6). Voor uit twee priemgetallen samengestelde modulus geldt dat een e waarvoor geldt ggd(e, φ(m)) = 1 een inverse heeft. 131

132

Valkuilen bij kleine exponenten in RSA

De hoeveelheid tijd die een encryptie of decryptie kost is proportioneel met log e respectievelijk log d. Het is dus nuttig om een van de exponenten e of d klein te kiezen als een van de apparaten veel trager is dan de ander, of als de ene bewerking veel vaker wordt gedaan. Bijvoorbeeld bij het ondertekenen van een certificaat (met je geheime exponent) dat vaak wordt gecontroleerd met de publieke exponent is het logisch om die publieke exponent klein te willen kiezen, mits dat niets aan de veiligheid af doet natuurlijk. We kunnen ook bij de geheime exponent p en q bewaren zodat we berekeningen nog sneller kunnen uitvoeren met behulp van de Chinese Reststelling. Dit is tot vier maal sneller bij het berekenen van een machtsverheffing. 14.1.1

De kraak

Definition 14.1 Een aanval op RSA is: Het vinden van de geheime exponent d uit de publieke informatie (m, e). Als we de factoren (p, q) van de modulus kennen kunnen we eenvoudig d uitrekenen. Het vinden van de factoren impliceert dus het vinden van de geheime exponent. Omgekeerd geldt dit ook: Gegeven (d, e) en de relatie d · e ≡ 1 mod φ(m) kunnen we de factoren uitrekenen. Het factoriseren van m is equivalent met het vinden van de geheime exponent. De cryptografische kracht van RSA zit hem erin dat het ondoenlijk is om de discrete logaritme of de wortel van een getal direct uit te rekenen.

14.2

Oude bekenden

Er zijn een aantal mogelijke aanvallen waar zeker rekening mee gehouden moet worden bij het implementeren van RSA. Alle alom bekende implementaties ontwijken de volgende valkuilen dan ook, maar voor de volledigheid lopen we ze toch even langs. 14.2.1

p − 1 of p + 1?

In 1974, dus voordat RSA ontworpen was, bewees Pollard dat een samengesteld getal m = pq eenvoudig gefactoriseerd kan worden als alle factoren van p−1 of q −1 klein zijn. [Pol74] Met een geheel andere methode lukte het Williams in 1982 dat een samengesteld getal ook gefactoriseerd kan worden als alle factoren van p + 1 of q + 1 klein zijn. [Wil82] Bij het willekeurig kiezen van de factoren p en q moet er dus wel gecontroleerd worden of deze geschikt zijn. 14.2.2

Kleine publieke exponent

Hastad heeft in 1985 de eerste aanval op een kleine publieke exponent bedacht. De aanval voldoet niet aan de eerder gedefinieerde doelen om de geheime exponent of de

14.3 Het kettingbreukalgoritme

133

modulus te kraken, maar decodeert wel het oorspronkelijke bericht. Neem een vaste kleine publieke exponent, bijvoorbeeld e = 3. Stel nu we sturen drie mensen hetzelfde bericht, uiteraard wel steeds met andere priemfactoren en modulus (m1 , m2 , m3 ). Dus bericht 1: y1 = x3 mod m1 , bericht 2: y2 = x3 mod m2 , bericht 3: y3 = x3 mod m3 . Met behulp van de Chinese Reststelling kunnen we x3 mod m1 m2 m3 berekenen. Er geldt x < m1 , m2 , m3 dus ook x3 < m1 , m2 , m3 . Dit is erg problematisch√want 3 als we niet modulair hoeven te rekenen kunnen we gewoon worteltrekken: x = x3 ! [Has85] Afgezien van deze aanval zijn er geen aanvallen bekend die gebruik maken van het feit dat e klein is, of die anderzins gebruiken maken van de keuze van e. Dit betekent dus dat er verder geen beperkingen op de keuze van e zijn. 14.2.3

Lokale kraken

Sinds 2005 kent de hele cryptografische wereld de zin ”Hyper-Threading Considered Harmful”. 13 Mei werd er door Colin Percival een presentatie gegeven over een aanval op RSA. [Per05] Hyperthreading processoren gaven tijdens een decryptie informatie over de geheime sleutel aan threads die tegelijkertijd draaiden. Zelfs aan threads met minimale rechten. Het bleek mogelijk om de geheime sleutel te achterhalen. Een recentere aanval, Branch Prediction Analysis [AKS06b], misbruikt ook rechten die worden verleent aan threads die op dezelfde processor draaien. Timing, BPA of iedere andere aanval die het ‘afluisteren’ van de processor door een aanvaller vereist kan voorkomen worden door de aanvaller die mogelijkheid tot ‘afluisteren’ te ontzeggen. Het zijn natuurlijk serieuze problemen die bij beveiligingssystemen als geheel zeker in beschouwing moeten worden genomen, maar kunnen niet als zwakheden van RSA worden gezien. Er wordt tenslotte niet slechts gebruik gemaakt van de publieke informatie zoals in de definitie 14.1 van de aanval is gespecificeerd.

14.3

Het kettingbreukalgoritme

Wiener beschreef in 1990 de eerste aanval op een RSA-variant waarbij gebruik wordt gemaakt van een kleine geheime exponent. Eerst moeten we even een belangrijke vergelijking opschrijven: µ ¶2 µ ¶2 p+q p−q p2 + q 2 + 2pq p2 + q 2 − 2pq − = − (14.1) pq = 4 4 2 2 µ µ ¶2 ¶2 p+q p−q − pq = (14.2) 2 2 Deze vergelijking geldt altijd en we kunnen deze zelfs gebruiken om een aanval te doen:

134


√ Als |p−q| = c· p (met c een constante en niet polynomiaal in p) worden de factoren √ in polynomiale tijd gevonden. Bereken p = pq en controleer of de vergelijking geldt. Loop nu alle kwadraten (gebaseerd op p en q gehele getallen) af. Lemma 14.2 Zodra vergelijking 14.2 twee gehele kwadraten oplevert zijn p en q gevonden en is de modulus gefactoriseerd. [Wie90] Een kettingbreuk is een vergelijking van de volgende vorm1 : f=

1 q1 +

1 q2 + q

3+

···+

1

... 1 qn−1 + q1 n

En hq1 , q2 , . . . , qn i heet de kettingbreukexpansie. Het kettingbreukalgoritme van Wiener benadert f , een functie van d, waarbij geldt 0 f = f (1 − δ) = pqe , δ ≥ 0. f 0 is dus een ondergrens voor f en daaruit wordt een gok van p+q afgeleid. Zodra dit een geheel getal is, hebben we de factoren van m gevonden 2 (Lemma 14.2) en kunnen we d berekenen. Het algoritme berekent iedere iteratie een extra quotient qi van de kettingbreukexpansie. Er zijn ten hoogste log(m) quotienten (iteraties) en de berekeningen van de benadering en de controle of het antwoord gevonden is kosten polynomiale tijd dus loopt het algoritme loopt in het geheel ook in polynomiale tijd in log(m). Het antwoord wordt gevonden als δ aan strenge eisen voldoet: Lemma 14.3 Als e < m, ggd(p−1, q−1) is klein en log(p) ≈ log(q) dan kunnen we met 1 behulp van het kettingbreukalgoritme geheime exponenten d < m 4 vinden. De grootte van d die we kunnen achterhalen is negatief afhankelijk van de grootte van ggd(p − 1, q − 1). [Wie90]

14.4

Het roosteralgoritme

Op basis van het Lenstra, Lenstra en Lovász-algoritme [LLL82] wist Coppersmith in 1997 een methode te bouwen om kennis van factoren te gebruiken bij het defactoriseren. De kern van de methode bestaat uit het vinden van nulpunten van modulaire ploynomiale vergelijkingen. Dit wordt gedaan door het factorisatieprobleem om te schrijven naar het zoeken van een kleine basis in een rooster. Coppersmith beschreef een aantal toepassingen van zijn methode, waaronder het aanvallen van RSA. De voor RSA twee belangrijkste lemma’s zijn als volgt: [Cop97] Lemma 14.4 Als we de ( 14 logm) meest significante bits van p kennen kunnen we in polynomiale tijd m = pq factoriseren. 1

Eigenlijk vereist een kettingbreuk niet dat alle noemers 1 zijn en schrijven we die apart als ha1 , a2 , . . . , an i, maar in het algoritme van Wiener geldt deze eis wel.

14.5 Uit balans

135

Lemma 14.5 Als we de ( 14 logm) minst significante bits van p kennen kunnen we in polynomiale tijd m = pq factoriseren. NB. Hij schrijft dat bits van p bekend moeten zijn, maar deze geven (omdat we m kennen) ook die bits van q. Coppersmith deed geen poging kennis van het klein zijn van de decryptie-exponent d te gebruiken. In 2000 werd er voor het eerst een verbetering gevonden op het werk van Wiener (zoals besproken in paragraaf 14.3). Boneh & Durfee gebruikten de methode van Coppersmith, met kleine aanpassingen. Ze gingen er vanuit dat q ≤ p ≤ 2q en e ≈ m. Als we nu efficient alle mogelijke kleine d (= e−1 ) kunnen opnoemen, kunnen we de modulus factoriseren. Ze bewezen ook dat er meestal een unieke kleine d is, binnen de gestelde voorwaarden. Uiteindelijk kwamen ze tot het volgende resultaat: Lemma 14.6 Gegeven q ≤ p ≤ 2q, e < m1.875 en d < m0.292 kan waarschijnlijk efficient de modulus gefactoriseerd worden. [BD00] Ze stelden in hun artikel twee open vragen: 1. Zekerheid geven over het resultaat. Ondanks dat geen enkel experiment faalde, konden ze hun theorie niet bewijzen. 2. Het verder oprekken van de grens d < m0.292 . Hun vermoeden is dat de grens 1 eigenlijk op m 2 moet liggen. Het verder oprekken van de grens is een van de belangrijke openstaande cryptografische problemen. [STO03]

14.5

Uit balans

In 2002 bedenkt May (uiteraard ook weer gebaseerd op de methode van Coppersmith) twee nieuwe aanvallen op RSA, beide gebruikmakend van de veronderstelling dat p en q niet gebalanceerd zijn, we definiëren q < mβ . Dit is wellicht niet realistisch, maar het is bedoeld als opzet voor een algoritme waarbij de factoren wel gebalanceerd zijn. Wat nieuw is aan de vraagstelling is dat May er vanuit gaat dat de Chinese Reststelling wordt gebruikt om de decryptie te versnellen; we nemen dus geen kleine d, maar een kleine dp = d mod p − 1. Het resultaat dat hij weet te boeken is een bewijsbare methode die werkt tot β < 0.382, waarbij de maximale kraakbare grootte van dp afhangt van β. En een tweede methode die heuristisch is, maar voor β < 0.23 met grotere waarden van dp (tot dp ≤ 1) succesvol de modulus weet te factoriseren. Bij beide methoden rest de vraag hoe gebruik gemaakt kan worden van de kennis dat dq ook klein is en natuurlijk hoe de methoden gecombineerd kunnen worden. [May02]

136


14.6

Staat van de kunst

Met hulp van Bleichenbacher heeft May in 2006 zijn twee methoden weten te combineren. [BM06] De nieuwe aanval werkt tot q < m0.468 , niet ver van het gebalanceerde geval dus en is strikt beter dan de methoden van May uit 2002. Interessant is dat de eerdere aanpak van May voor kleine dp sterk lijkt op die van Boneh & Durfee (zie 14.4) voor kleine d en het is een open vraag of de verbeteringen analoog kunnen worden toegepast. De verwachting is dat het niet lang meer duurt voordat deze aanval uitgebreid wordt naar gebalanceerde factoren. Let op: de maximale grootte van dp en dq hangt wel nog steeds af van de balans tussen p en q. In hetzelfde artikel wordt ook een aanval uit de doeken gedaan voor gebalanceerde factoren, maar met de aanvullende eis dat e ook klein is. Om precies te zijn: 2 1 dp , dq < min{ 14 (m/e) 5 , 13 m 4 }. Deze aanval werkt2 op 2 kleine exponent RSA varianten die voorgesteld werden in 2005 door Galbraith et al. [GHM05] & Sun, Wu [SW05].

Samenvatting en conclusies Zoals de oplettende lezer heeft kunnen concluderen zijn er nog behoorlijk wat open vraagstukken wat betreft het kraken van RSA met kleine modulus. Zowel het resultaat van Boneh & Durfee voor gebalanceerde factoren en kleine d als het resultaat van Bleichenbacher & May voor ongebalanceerde factoren en kleine dp liggen met smart te wachten op verbetering. . . Verder zijn tot nu toe de cryptografen het er wel over eens dat wanneer voor RSA gewoon een grote modulus m gebruikt wordt, bestaande uit (geschikte) factoren p en q 1 die ongeveer even groot zijn en de geheime exponent d > m 2 wordt gekozen, dat het algoritme adequate beveiliging biedt.

2

Na publicatie van het artikel van Bleichenbacher & May zijn beide voorgestelde varianten zo aangepast dat de aanval niet langer werkt.

Hoofdstuk 15 Een geheugen effici¨ ente achterdeur in RSA Door Jos Roseboom

Dit hoofdstuk gaat over een methode om verloren RSA sleutel terug te halen met behulp van een supersleutel. Deze methode vergt weinig geheugenopslag. Het versturen van versleutelde boodschappen is aan de orde van de dag. De reden hiervoor ligt voor de hand: de boodschap die versleuteld wordt mag niet aan onbevoegden bekend worden, terwijl de beoogde ontvanger wel kennis van deze boodschap dient te krijgen. Dit doel is met kennis van de huidige cryptografische algoritmen goed te realiseren. Gaat het hier om een op zichzelf staande boodschap die Alice en Bob, beiden met niemand iets te maken, naar elkaar willen sturen, is hier de kous wel mee af. Er zijn situaties waarin dit niet het geval is. Hierbij kunnen we denken aan een hierarchische structuur. Op een bepaald niveau wordt er (versleuteld) gecommuniceerd. Een bijzondere eis die we nu stellen is dat iemand die zich op een hoger niveau bevindt, de boodschappen kan ontsleutelen, terwijl de boodschappen voor ieder ander onzichtbaar blijven. Om dit te kunnen bewerkstelligen moet er een achterdeurtje in de beveiliging zitten, waardoor personen van een hoger niveau zich toegang kunnen verschaffen. Zo’n achterdeurtje wordt SETUP genoemd, wat staat voor “secretly embedded trapdoor with universal protection”. De SETUP waar dit hoofdstuk over gaat, maakt gebruik van eigenschappen van elliptische krommen. Een gebruikelijke oplossing voor dit probleem is het versleuteld opslaan van alle sleutels. Deze methode kost echter veel geheugen, en vereist veel aandacht in het up-to-date houden.

137

138

Een geheugen efficiënte achterdeur in RSA

15.1 15.1.1

Elliptische krommen Punten van een elliptische kromme

De methoden die in dit hoofdstuk aan het licht komen maken gebruik van de eigenschappen van elliptische krommen. Zo’n elliptische kromme heeft niets met ellipsen te maken en een wiskundige kromme is het ook niet echt. Een elliptische kromme bestaat uit een eindige set punten. Deze eindige set vormt samen met de groepsoperaties een eindig lichaam. Dit lichaam heeft een orde, die gelijk is aan het aantal elementen in het lichaam. Een eindig lichaam van orde q is er alleen dan en slechts dan als q een priemmacht is. Als dit het geval is, is er ook maar één corresponderend lichaam met orde q. Dit lichaam geven we aan met Fq . Als nu q = pm , met m ≥ 1, noemen we p de karakteristiek van q, en m de uitbreidingsgraad van Fq . Om wille van de veiligheid willen we de orde groot maken. Dit kunnen we bereiken door de karakteristiek (p) groot te maken, of de uitbreidinggraad (m) groot te maken. Een combinatie van een grote karakteristiek en een grote uitbreidingsgraad is mogelijk, maar in de praktijk kiest men vaak voor een grote karakteristiek met uitbreidingsgraad 1, of de kleinst mogelijke karakteristiek, 2, met een grote uitbreidingsgraad. In het laatste geval wordt voor m een oneven priemgetal gekozen, om weerstand te bieden aan een GHS aanval [GHS02]. Hier ga ik verder niet op in. De lichamen die gebruikt worden zijn dan Fp , ook wel het priemlichaam, of F2m , ook wel het binair eindige lichaam. Bij het binair eindige lichaam wordt er niet gereduceerd met een getal, maar met een polynoom. Dit polynoom wordt het reductiepolynoom genoemd. Het reductiepolynoom mag zelf niet reduceerbaar zijn, wat betekent dat het niet geschreven kan worden als het product van meerdere polynomen van een lagere graad. Niet alle punten zijn element van de kromme die het lichaam bepaalt. Hoe te bepalen welke punten element van de kromme zijn hangt af van de orde (2-macht of priemgetal). Definition 15.1 De elliptische kromme Eq,a,b , met q een priemgetal, bevat de verzameling paren (x,y) ∈ Zq × Zq die voldoen aan y 2 = x3 + a · x + b, en een speciaal punt ∞. Definition 15.2 De elliptische kromme Eq,a,b , met q een 2-macht en b 6= 0, bevat de verzameling paren (x,y) modulo f(x), met f(x) het reductiepolynoom, die voldoen aan y 2 + x · y = x3 + a · x2 + b, en een speciaal punt ∞. In dit hoofdstuk houden we ons verder alleen bezig met binair eindige lichamen. Een interessante vraag is hoeveel punten een kromme bevat. De Duitse wiskundige Helmut Hasse kwam tot de volgende stelling (stelling van Hasse): √ √ q − 2 q + 1 ≤ #Eq,a,b ≤ q + 2 q + 1 Het opslaan van een punt op de kromme zou 2 · lg q bits kosten als we de waarde voor x en de waarde voor y los van elkaar op zouden slaan Dit kan echter efficienter, omdat niet alle waarden voor y mogelijk zijn als de waarde voor x vast ligt. Beschouwen we de waarde voor x als bekend, houden we een vergelijking van graad 2 over (zowel bij de priemlichamen als bij de binair eindige lichamen). Daar een vergelijking van graad

15.1 Elliptische krommen

139

Kader 15.1: Intu¨ıtie bij groepsoperatie Om de groepsoperatie van elliptische krommen iets tastbaarder te maken, staat in dit kader een afbeelding die iets meer op de intu¨ıtie van de lezer inspeelt. Het eerste plaatje geeft aan wat er gebeurt als je een punt bij zichzelf op wilt optellen. Er wordt dan een raaklijn langs dat punt getrokken, en het andere punt wat deze raaklijn snijdt is het tegenovergestelde van het resultaat van de puntverdubbeling. Het tweede plaatje geeft aan wat er gebeurt als 2 verschillende punten bij elkaar op worden geteld. De lijn door P en Q gaat ook door het tegenovergestelde van het resultaat. Voor de punten in het plaatje geldt dus dat P + Q = −R. 2 ten hoogste 2 oplossing heeft, kunnen we in het opslaan van het punt (x, y) volstaan met het opslaan van x en een extra bit die beschrijft welke van de 2 mogelijke waarden voor y de waarde is die in het beoogde punt zit. Deze manier heet puntcompressie en het opslaan van een punt kost op deze manier slechts lg q + 1 bits. 15.1.2

De groepsoperatie

De groepsoperatie neemt twee punten en beeldt deze af op een derde. De intu¨ıtie is dat er een rechte lijn (een lijn van de vorm y = c · x + d) getrokken wordt door de twee punten. Het punt waar deze twee middels de groepsoperatie op afgebeeld worden is het tegenovergestelde van het derde snijpunt van de rechte lijn met de elliptische kromme. Voor de groep van de elliptische krommen over F2m geldt [JM99] : 1. De identiteit is ∞. 2. De inverse van ∞ is −∞ = ∞. De inverse van P = (x, y) is −P = (x, x + y). −P is ook een punt op de elliptische kromme. 3. Voor alle P is ∞ + P = P + ∞ = P . 4. (Punt optelling) Als P = (x1 , y1 ) en Q = (x2 , y2 ), met P 6= ±Q, dan geldt P + Q = (x3 , y3 ), met µ x3 =

y1 + y2 x1 + x2

en y3 =

¶2 +

y1 + y2 + x1 + x2 + a x1 + x2

y1 + y2 · (x1 + x3 ) + x3 + y1 x1 + x2

140


5. (Punt verdubbeling) Als P = (x1 , y1 ), met P 6= −P , dan geldt 2P = (x3 , y3 ) met x3 = x21 + en

µ y3 =

x21

+ x1 +

b x21 ¶

y1 x1

· x3 + x3

De eerste indruk zou kunnen zijn dat er bij punt verdubbeling de eis mist dat x1 6= 0 is, maar deze eis zit impliciet in de eis dat P 6= −P . Als geldt dat P = (x1 , y1 ) = (0, y1 ), dan geldt −P = (x1 , x1 + y1 ) = (0, y1 ), waardoor P = −P . Deze groep voldoet aan de eisen voor een Abelse of commutatieve groep. In Casus 15.1 wordt intu¨ıtief geschetst hoe de groepsoperatie in zijn werk gaat. 15.1.3

Elliptische kromme Diffie-Hellman

We hebben een black box die sleutels genereert voor RSA. Deze RSA sleutels kunnen later teruggehaald worden door de ontwerper van de black box, door het aangaan van een elliptische kromme Diffie-Hellman protocol van de ontwerper met de black box. Het normale Diffie-Hellman sleuteluitwisselings protocol [WD88] houdt in dat zowel Alice als Bob een geheime sleutel x bedenken en een publieke sleutel y = g x bepalen. De publieke sleutels worden uitgewisseld en de gezamelijke geheime sleutel wordt berekend xeigen als k = yontvangen . Beide beschikken nu over dezelfde geheime sleutel k = g xAlice ·xBob Het elliptische kromme Diffie-Hellman protocol rust op hetzelfde principe. Bekend is: m 2-macht van de modulus fx Het reductiepolynoom a,b Parameters van de elliptische kromme G Basispunt op de elliptische kromme n De orde van G (G ≥ 2160 ) h Co-factor = #E2m ,a,b /n Het genereren van een sleutel gebeurt door het kiezen van een willekeurig getal d ∈ 1 . . . n − 1. Dan wordt de publieke sleutel bepaald door y = d·G en deze worden ook uitgewisseld. De gezamelijke geheime sleutel wordt berekend als k = yontvangen · xeigen . Beide beschikken nu over de dezelfde geheime sleutel k = dAlice · dBob · G. Voor een eventuele aanvaller is dit minstens zo moeilijk als de discrete logaritme. Als d = 280 wordt gekozen, kan door steeds het resultaat bij zichzelf op te tellen in 80 stappen d · G worden uitgerekend. Een aanvaller deze truc niet gebruiken om d uit y te bepalen, en moet hiertoe het ondoenlijke aantal van 280 stappen maken. Dit is vergelijkbaar met het bepalen van de discrete logaritme. Voor het discrete logaritme probleem is er echter nog de index calculus. Een equivalent van de index calculus voor de elliptische krommen bestaat er (nog) niet, waardoor het bepalen van het gekozen getal d minstens zo moeilijk is als het bepalen van de discrete logaritme.

15.1 Elliptische krommen

15.1.4

141

Relaties tussen krommen: de ”twist”

Een kromme heeft niet voor elke waarde van x een waarde voor y. Bij een waarde voor x zijn er 0,1 of 2 waarden voor y (invullen van een waarde voor x laat een tweede graads vergelijking in y over). Soms (hierover later meer) is het wenselijk dat er voor elke waarde van x een waarde voor y beschikbaar is. Dit kunnen we doen door met meerdere elliptische krommen te werken, en zo te zorgen dat er voor elke waarde van x een kromme beschikbaar is die bij die waarde van x een waarde van y heeft. Het mooiste is het wanneer er twee elliptische krommen zijn die elkaar precies aanvullen, dat wil zeggen, overal bestaan waar de andere niet bestaat, en slechts op een raakpunt een overlap van één punt hebben. Twee krommen die aan deze eigenschap voldoen worden elkaars “twist” genoemd. Als twee krommen elkaars twist zijn, zijn er twee mogelijkheden: √ • (x, y) = (0, b) ligt op beide krommen • (x, y) en (x, x + y) liggen op één van beide krommen De waarheid van het eerstgenoemde laat zich aantonen door het invullen van de waarde 0. y 2 + 0 · y = 03 + a · 02 + b y2 = b √ y = ± b Door de waarde 0 speelt de waarde van a geen rol van betekenis meer. De coördinaten voor de situatie dat ze op één van de krommen liggen is iets minder triviaal. Om dit aan te tonen, houden we in gedachte dat voor een 2e graads vergelijking geldt: (y − yopl1 ) · (y−opl2 ) = y2 − (yopl1 + yopl2 ) · y + yopl1 · yopl2 Herschrijven leidt tot: y 2 + x · y = x3 + a · x2 + b y 2 + x · y + (−x3 − a · x2 − b = 0 Nu geldt dat: y 2 + x · y + (−x3 − a · x2 − b = y2 − (yopl1 + yoplossing2 ) · y + yopl1 · yopl2 x = −(yopl1 + yopl2 ) yopl1 = −(x + yopl2 ) In F2m geldt dat Z = −Z, waardoor geldt dat −(x + yopl2 ) = x + y Daar er voor elke x precies 2 punten bestaan op de kromme en zijn twist, is de som van de punten op beide krommen 2m+1 + 2. Het optellen van 2 komt door de punten ∞ die ook nog bij beide krommen horen.

142


Hoe vind je nou de twist van een kromme? Als de “traces” over F2 van a en a0 ongelijk zijn, dus T rF2m /F2 (a) 6= T rF2m /F2 (a0 ), dan zijn Ea,b en Ea0 ,b twists van elkaar. De trace wordt als volgt bepaald: m−1 X i T r(a) = a2 i=0

De functie T rF2m /F2 (a) neemt de trace van a modulo 2 en heeft dus als uitkomst 0 of 1 (even of oneven). Het bepalen van waarden voor a en a0 is niet ingewikkeld. De waarde m is oneven gekozen, waardoor gesommeerd wordt over een onevenen aantal machten van a. Hieruit volgt dat T rF2m /F2 (0) = 0 en T rF2m /F2 (1) = 1. De krommen E0,b en E1,b zijn dus twists van elkaar.

15.2

SETUP

15.2.1

Sterke SETUP

Het algoritme wat in dit hoofdstuk behandeld wordt is een SETUP (“secretly embedded trapdoor with universal protection”) voor RSA [RSA78b]. Aan een SETUP kunnen wat extra eisen gesteld worden, wat ook hier hier geval is [YY06]. 1 (Ononderscheidbaarheid) De in dit hoofdstuk behandelde SETUP zit ingebakken in een sleutelgeneratie black box. Er is nu een onderzoeker die gebruik mag maken van een black box die gebruik maakt van SETUP en van een black box die dat niet doet. Ononderscheidbaarheid wil zeggen dat er geen mogelijkheid is dat deze onderzoeker met een kans groter dan 50% kan bepalen welke black box gebruik maakt van SETUP. 2 (Vertrouwelijkheid) Het moet voor iemand die alleen op de hoogte is van publieke sleutels niet mogelijk zijn om de geheime sleutels te achterhalen. 3 (Compleetheid) Als iemand de supersleutel bezit, kan hij elke geheime sleutel terughalen. 4 (Uniformiteit) Elke black box die voorzien is van SETUP, is gelijk. Definition 15.3 Als een SETUP voldoet aan de eisen 1,2,3 en 4, is het een sterke SETUP Dat de eisen 2,3 en 4 gehaald worden, is duidelijk na bestudering van het algoritme. Eis 1 (Ononderscheidbaarheid) ligt iets subtieler. Met de voorgestelde SETUP worden sleutels gegenereerd aan de hand van een elliptische kromme. Er punt wordt een groot aantal keren verdubbeld, en de x-coördinaat wordt als sleutel gebruikt. Op een elliptische kromme heeft echter niet elke x-coördinaat even veel corresponderende ycoördinaten. Nemen we de gehele verzameling van punten, zien we een scheve verdeling van de x-coördinaten. Eén groep komt helemaal niet voor (geen corresponderende ycoördinaat), één groep komt wel een aantal keer voor(1 corresponderende y-coördinaat)

15.2 SETUP

143

en één groep komt 2 keer zo vaak voor als de andere wel voorkomende groep(2 corresponderende y-coördinaten). Daar de x-coördinaat als sleutel wordt genomen, ontstaat er een scheve verdeling van de sleutels die de black box uitgeeft. Een onderzoeker prikt hier zo doorheen, en ontmaskert de SETUP. Er wordt niet voldaan aan de eis van ononderscheidbaarheid. Dit probleem wordt opgelost door het gebruikt van 2 elliptische krommen, waarbij de één de twist is van de ander. Door in de black box van beide krommen gebruik te maken, zijn er voor elke x-coördinaat 2 corresponderende y-coördinaten, wat zorgt voor een uniforme verdeling van de x-coördinaten over alle punten en daarmee voor een uniforme verdeling van de sleutels. Een onderzoeker ziet nu geen verschil meer tussen de black box die uitgerust is met SETUP en de black box zonder, waarmee we voldoen aan de eis van ononderscheidbaarheid. 15.2.2

De Black Box

In de black box zitten 4 waarden die de ontwerper bepaald heeft, namelijk G0 , G0 , Y0 en Y1 . Hier is de waarde Ga het basispunt van de elliptische kromme Ea,b . Ya wordt bepaald door Ya = xa · Ga . De ontwerper is de enige die kennis heeft van de geheime sleutels x0 en x1 , de supersleutels. De black box voert de volgende stappen uit, waarna het een Diffie-Hellman sleutelpaar teruggeeft: 1. Kies a = 0 of a = 1 2. Kies k willekeurig, met 0 ≤ k ≤ n (met n de orde van generator G) 3. Bepaal Spub = k · Ga 4. Bepaal Sgeh = k · Ya 5. Return (Spub , Sgeh ) De sleutels worden gecomprimeerd teruggegeven. De compressie geschied als beschreven in 15.1.1. Als we nu een verloren sleutelpaar terug willen halen, hebben we de publieke sleutel nodig, en de 2 supersleutels. Dit gaat als volgt (DHsleutelherstel): 1. Controleer of a = 0 of a = 1 2. Return Sgeh = xa · Spub = xa · k · Ga = k · xa · Ga = k · Ya 15.2.3

Gebruik van de black box

Met het verkrijgen van een Diffie-Hellman sleutelpaar zijn we nog niet bij een RSA sleutelpaar. Om dit voor elkaar te krijgen gebruiken we een methode die een priemgetal genereert aan de hand van een bitstring (s), de lengte die het gegenereerde priemgetal moet hebben (len) en een RSA exponent e. Deze methode maakt gebruik van R(s) : 0, 1∗ → 0, 1∞ . R(s) kan willekeurig lange input genereren en geeft met een gelijke s een gelijk resultaat. Een andere methode die gebruikt wordt is GetBlock(s, i, j), die van bitstring s, vanaf positie i de eerste j bits teruggeeft. De priemgeneratie methode doet het volgende:

144


1. T eller = 0, kies T, waarbij geldt |n|/4 ≤ T ≤ len 2. u = GetBlock(R(s), T eller · T, T ) 3. Kies ` ∈R {0, 1}len−T 4. p is het getal dat correspondeert met de bit string u||` 5. Controleer of p een goed priemgetal is aan de hand van len en e 6. Als p een goed priemgetal is, return p, anders neem T eller = T eller + 1 en ga naar stap 2 De methode priemgeneratie levert een priemgetal op. Om daar een goed RSA sleutelpaar van de maken, hebben we de methode RSAgeneratie, die gegeven een DiffieHellman sleutelpaar een RSA sleutelpaar genereert. N/2 is hier de bitlengte van de priemgetallen in n De RSAgeneratie methode doet het volgende: 1. p = priemgeneratie(Sgeh , N/2, e) 2. s =∈R {0, 1}θ−(m+1) 3. t = πθ (s||Spub ), met πθ een permutatie 4. s =∈R {0, 1}N −θ 5. nkandidaat = t||r 6. los op: nkandidaat = p · q + rest 7. Controleer of q een goed priemgetal is aan de hand van N/2 en e 8. Als q een goed priemgetal is, return (p, q), anders ga naar stap 2 In zowel priemgeneratie als RSAgeneratie wordt aan de hand van lengte en RSA exponent gecontroleerd of een getal een goed priemgetal is. Deze controle bestaat uit de stappen: • Als het kandidaat priemgetal niet even lang als de lengte, is het geen goed priemgetal • Als de belangrijkste 2 bits van het kandidaat priemgetal ongelijk ’11’ zijn, is het geen goed priemgetal • Als het kandidaat priemgetal een samengesteld getal is, is het geen goed priemgetal • Als de grootste gemene deler van e en het kandidaat priemgetal-1 ongelijk aan 0 is, is het geen goed priemgetal • Als bovenstaande 4 niet aan de orde zijn, is het een goed priemgetal


145

Het verkrijgen van een RSA sleutelpaar doe je nu door eerst een Diffie-Hellman sleutelpaar te vragen uit de black box. Met dit sleutelpaar als invoer roep je de methode RSAgeneratie aan, die je je RSA sleutelpaar terug geeft. Hoe kunnen we nu dit sleutelpaar reconstrueren als het onbekend is? De Amerikaanse wiskundige Don Coppersmith heeft aangetoond dat als de |n|/4 meest significante bits van een van de priemgetallen bekend zijn [Cop96], deze op een efficiënte manier ontbonden kan worden. Bij het genereren van een priemgetal in priemgeneratie vormt u de T meest significante bits, met |n|/4 ≤ T ≤ len. Het achterhalen van u maakt het dus mogelijk om met de methode van Coppersmith de modulus efficient te ontbinden, waarmee de sleutels ook geen geheim meer zijn. De sleutelherstel methode onbindt aan de hand van de modulus en de geheime sleutels van de ontwerper (x0 enx1 ) van de black box en doet dat als volgt: 1. t = GetBlock(ns , 0, θ), waar ns de bitstring behorende bij de modulus n is. 2. Spub = GetBlock(πθ−1 (t), θ − (m + 1), m + 1) 3. Sgeh = DHsleutelherstel(Spub , x0 , x1 ) 4. T eller = 0, kies T = |n|/4 5. u = GetBlock(R(s), T eller · T, T ) 6. Probeer n te ontbinden door het aanroepen van Coppersmiths algoritme [Cop96] met de parameters u en n. Return de ontbinding als Coppersmith slaagt, anders T eller = T eller + 1. 7. Als T eller ≤ M AX ga naar stap 5. 8. Return failure Er is een maximaal aantal pogingen, omdat het zou kunnen dat er naar een ontbinding wordt gevraagd van een modulus die niet afkomsting in van een RSA sleutelgenerator die gebruik maakt van SETUP. In dat geval vindt dit algoritme natuurlijk ook geen ontbinding.

Samenvatting en conclusies In dit hoofdstuk heb ik een methode onder de aandacht gebracht die het mogelijk maakt aan de hand van een tweetal supersleutels en een publieke sleutel een geheime sleutel te achterhalen. Dit vertaalt zich naar RSA door de mogelijkheid de modulus te ontbinden met kennis van de supersleutels. In vergelijking met het versleuteld opslaan van alle sleutels, gebruikt deze methode verwaarloosbaar geheugen. In plaats van het opslaan van alle sleutels die uitgegeven worden, hoeven alleen de supersleutels nog maar bewaard te blijven.

146


Bibliografie

[ABS05]

Alex Biryukov, S. M. and Sarkar, P. Improved time-memory tradeoffs with multiple data, 2005. www.esat.kuleuven.ac.be/~abiryuko.

[AKS06a]

Acıic ¸ mez, O., Koc ¸, C ¸ . K., and Seifert, J.-P. On the power of simple branch prediction analysis. Cryptology ePrint Archive, Report 2006/351, 2006. http://eprint.iacr.org/2006/351.

[AKS06b] Aciicmez, O., Koc, C. K., and Seifert, J.-P. On the power of simple branch prediction analysis. Cryptology ePrint Archive, Report 2006/351 (2006). http://eprint.iacr.org/. [AL82]

A.K. Lenstra, H. L. . L. L. Factoring polynomials with polynomial coefficients. Math. Annalen (1982).

[ASK06]

Acıic ¸ mez, O., Seifert, J.-P., and Koc ¸, C ¸ . K. Predicting secret keys via branch prediction. Cryptology ePrint Archive, Report 2006/288, 2006. http://eprint.iacr.org/2006/288.

[BB05]

Brumley, D. and Boneh, D. Remote timing attacks are practical. Computer Networks 48, 5 (2005), 701–716. http://dx.doi.org/10.1016/j.comnet.2005.01.010.

[BD00]

Boneh, D. and Durfee, G. Cryptanalysis of rsa with private key d less than n0.292 . IEEE Transactions on Information Theory 46, 4 (2000), 1339–1349.

[BD06]

Biondi, P. and Desclaux, F. Silver needle in the skype, 2006. http:\\www.secdev.org/conf/skype_BHEU06.handout.pdf.

[Ber05]

Berson, T. Skype security evaluation, 2005. www.skype.com/security/files/2005-031%20security%20evaluation.pdf.

[blua]

blug.linux.no. The higly unofficial cpip wg. http://www.blug.linux.no/rfc1149/. 147

148

Bibliografie

[blub]

blug.linux.no. The informal report from the rfc 1149 event. http://www.blug.linux.no/rfc1149/writeup.html.

[BM06]

Bleichenbacher, D. and May, A. New attacks on rsa with small secret crt-exponents. Lecture Notes in Computer Science 3958 (2006), 1–13.

[BS00]

Biryukov, A. and Shamir, A. Cryptanalytic time/memory/data tradeoffs for stream ciphers. Lecture Notes in Computer Science 1976 (2000), 1+. citeseer.ist.psu.edu/474364.html.

[BWM98] Blake-Wilson, S. and Menezes, A. Authenticated Diffie–Hellman key agreement protocols. In proc. Selected Areas in Cryptography (1998), vol. 1556 of LNCS, pp. 339–361. [Cam05]

Cameron, K. The laws of identity.

[Cav99]

Cavoukian, A. Biometrics and policing: Comments from a privacy perspective. 10–12.

[CCK+ ]

Chan, S., Conti, D., Kaler, C., et al. Devices Profile for Web Services. http://specs.xmlsoap.org/ws/2006/02/devprof/devicesprofile.pdf.

[CDFT98] Callas, J., Donnerhacke, L., Finney, H., and Thayer, R. OpenPGP Message Format, RFC 2440. Network Working Group, November (1998). [Con]

Consortium, W. W. XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). http://www.w3.org/TR/xhtml1/.

[Cop96]

Coppersmith, D. Finding a small root of a bivariate intgere equation; factoring with high bits known. Eurocrypt ’96 (1996), 178–189.

[Cop97]

Coppersmith, D. Small solutions to polynomial equations and low exponent vulnerabilities. Journal of Cryptology 10, 4 (1997), 223–260.

[Cry]

Cryptolab, N. The NTRU public key cryptosystem: Enhancements I. NTRU .

[EBS06]

Elad Barkan, E. B. and Shamir, A. Rigorous bounds on cryptanalytic time/memory tradeoffs, 2006.

[Eck85]

Eck, W. van. Electromagnetic radiation from video display units: an eavesdropping risk? Computers & Security 4, 4 (1985), 269–286.

[Ell]

Ellison, C. UPnP Security Ceremonies http://www.upnp.org/download/standardizeddcps/ remonies 1 0secure.pdf.

Design Document. UPnPSecurityCe-


149

[Fora]

Force, I. E. T. Simple Service Discovery Protocol. http://quimby.gnus.org/internet-drafts/draft-cai-ssdp-v1-03.txt.

[Forb]

Forum, U. UPnP Device Architecture. http://www.upnp.org/download/UPnPDA10_20000613.htm.

[Forc]

Forum, U. Upnp website. http://www.upnp.org/about/default.asp.

[GHM05]

Galbraith, S., Heneghan, C., and McKee, J. Tunable balancing of rsa. Proceedings of ACISP, Lecture Notes in Computer Science 3574 (2005), 280–292.

[GHS02]

Gaudry, P., Hess, F., and Smart, N. Constructive and destructive facets of weil descent on elliptic curves. Journal of Cryptology, 15 (2002), 19–46.

[GLLM05] Goethals, B., Laur, S., Lipmaa, H., and Mielik¨ ainen, T. On private scalar product computation for privacy-preserving data mining. In proc. Information Security and Cryptology - ICISC 2004 (2005), vol. 3506 of Lecture Notes in Computer Science, Springer, pp. 104–120. [Gro]

Group, N. W. Dynamic Configuration of IPv4 Link-Local Addresses. http://tools.ietf.org/html/rfc3927.

[Has85]

Hastad, J. On using rsa with low exponent in a public key network. Advances in Cryptology - CRYPTO ’85 Proceedings, Lecture Notes in Computer Science (1985), 403–408.

[Hem06]

Hemel, A. Universal plug and play: Dead simple or simply deadly. Sane (2006). http://www.sane.nl/sane2006/program/final-papers/R6.pdf.

[HS97]

Hall, C. and Schneier, B. Remote electronic gambling, 1997.

[JFS00]

Jean-Fran c. R. and Stiglic, A. Security Issues in the Diffie–Hellman Key Agreement Protocol, 2000. http://citeseer.ist.psu.edu/article/raymond00security.html.

[JKS02]

Jallad, K., Katz, J., and Schneier, B. Implementation of ChosenCiphertext Attacks against PGP and GnuPG. Information Security, 5th International Conference 2433 (2002), 90–101.

[JM99]

Johnson, D. and Menezes, A. The elliptic curve digital signature algorithm (ECDSA).

[JSHJ98]

Jakobsson, M., Shriver, E., Hillyer, B. K., and Juels, A. A practical secure physical random bit generator, 1998.

150

Bibliografie

[K+ 04]

Konstantinou, E. et al. Electronic national lotteries. Lecture Notes in Computer Science 3110 (2004), 147–163.

[KAMa]

Anagram laboratories. http://www.anagram.com/.

[KAMb]

Hmac - wikipedia, the free encyclopedia. http:\\en.wikipedia.org/wiki/HMAC.

[KC04]

Kantarcioglu, M. and Clifton, C. Privacy-preserving distributed mining of association rules on horizontally partitioned data. IEEE Transactions on Knowledge and Data Engineering 16, 9 (2004), 1026–1037.

[Ker83]

Kerckhoffs, A. La cryptographie militaire.

[KJJ98]

Kocher, P., Jaffe, J., and Jun, B. Introduction to differential power analysis and related attacks. Whitepaper, 1998. http: //www.cryptography.com/resources/whitepapers/DPATechInfo.pdf, http://www.cryptography.com/resources/whitepapers/DPATechInfo.pdf.

[KJJ99]

Kocher, P. C., Jaffe, J., and Jun, B. Differential power analysis. In proc. CRYPTO ’99: Proceedings of the 19th Annual International Cryptology Conference on Advances in Cryptology (London, UK, 1999), SpringerVerlag, pp. 388–397.

[Knu05]

Knudsen, L. R. Smash - a cryptographic hash function. In proc. FSE (2005), H. Gilbert and H. Handschuh (eds.), vol. 3557 of Lecture Notes in Computer Science, Springer, pp. 228–242.

[Koc96]

Kocher, P. C. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In proc. CRYPTO ’96: Proceedings of the 16th Annual International Cryptology Conference on Advances in Cryptology (London, UK, 1996), Springer-Verlag, pp. 104–113.

[Kra05]

Krawczyk, H. HMQV: A High-Performance Secure Diffie–Hellman Protocol. In proc. Advances in Cryptology — CRYPTO 2005 (2005), vol. 3621 of LNCS, pp. 546–566.

[KS00]

Katz, J. and Schneier, B. A chosen ciphertext attack against several e-mail encryption protocols. Ninth USENIX Security Symposium (2000).

[KSWH00] Kelsey, J., Schneier, B., Wagner, D., and Hall, C. Side channel cryptanalysis of product ciphers. Journal of Computer Security 8, 2/3 (2000). [LLL82]

´ sz. Factorin polynomials with Lenstra, A., Lensta, H., and L.Lova rational coefficients. Mathmatische Annalen 261 (1982), 515–534.


151

[LM06]

Lauter, K. and Mityagin, A. Security Analysis of KEA Authenticated Key Exchange Protocol. In proc. Public Key Cryptography - PKC 2006 (2006), vol. 3958 of LNCS, pp. 378–394.

[LOU]

The Side Channel Cryptanalysis Lounge. http://www.crypto. ruhr-uni-bochum.de/en_sclounge.html, http://www.crypto.ruhr-uni-bochum.de/en_sclounge.html.

[LR]

Liskov, M. and Rivest, R. Tweakable block ciphers. citeseer.ist.psu.edu/liskov02tweakable.html.

[May02]

May, A. Cryptanalysis of unbalanced rsa with small crt-exponent. Advances in Cryptology – Crypto 2002, Lecture Notes in Computer Science 2442 (2002), 242–256.

[MZ05]

Mister, S. and Zuccherato, R. An Attack on CFB Mode Encryption As Used By OpenPGP.

[NHG]

N. Howgrave-Graham, J. Hoffstein, J. P. . W. W. On estimating the lattice security of NTRU. NTRU .

[NIS98]

NIST. SKIPJACK and KEA Algorithm Specification, 1998. http://csrc.nist.gov/encryption/skipjack/skipjack.pdf.

[Per05]

Percival, C. Cache missing for fun and profit, 2005. http://www.daemonology.net/papers/htt.pdf.

[Pol74]

Pollard, J. Theorems on factorization and primality testing. Proc. Cambridge Philos. Soc. 76 (1974), 521–528.

[PRR05]

Pramstaller, N., Rechberger, C., and Rijmen, V. Breaking a new hash function design strategy called smash. In proc. Selected Areas in Cryptography (2005), B. Preneel and S. E. Tavares (eds.), vol. 3897 of Lecture Notes in Computer Science, Springer, pp. 233–244.

[PV03]

Prins, C. and Vries, M. de. Id or not to be? naar een doordacht stelsel voor digitale identificatie.

[QK02]

Quisquater, J.-J. and Koeune, F. State-of-the-art regarding side channel attacks, 2002. http://www.ipa.go.jp/security/enc/CRYPTREC/ fy15/doc/1047_Side_Channel_report.pdf.

[QS00]

Quisquater, J.-J. and Samyde, D. A new tool for non-intrusive analysis of smart cards based on electro-magnetic emissions: the SEMA and DEMA methods. Eurocrypt rump session, 2000.

[RSA78a]

Rivest, R., Shamir, A., and Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM 21, 2 (1978), 158–164.

152

Bibliografie

[RSA78b] Rivest, R., Shamir, A., and Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM 21, 2 (1978), 120–126. [Sch98]

Schneier, B. Side-channel attacks against cryptosystems. Crypto-Gram Newsletter, 1998. http://www.schneier.com/crypto-gram-9806.html# side, http://www.schneier.com/crypto-gram-9806.html#side.

[Sch99]

Schneier, B. Inside risks: risks of relying on cryptography. Commun. ACM 42, 10 (1999), 144.

[Sci04]

Scientific Games Corporation. Scientific games signs contract with loter´ıa electrónica de puerto rico for online lottery, 2004.

[Sci05]

Scientific Games Corporation. Loter´ıa electrónica and scientific games launch successful conversion, 2005.

[SF06]

Siebes, A. P. J. M. and Feelders, A. J. Association rules. Lecture Notes for a University of Utrecht Course in Advanced Data Mining, 2006.

[Sil99]

Silverman, J. Almost inverses and fast NTRU key creation. NTRU (1999).

[Sil00]

Silverman, J. H. . J. Optimizations for ntru. NTRU (2000).

[Spy]

Spyrus. FORTEZZA and Jumbo FORTEZZA Series II Crypto Cards. http://spyrus.com/products/fortezza_cryptocard.asp.

[STO03]

STORK. Strategic roadmap for crypto, 2003. http://www.stork.eu.org/index.html.

[SW05]

Sun, H.-M. and Wu, M.-E. An approach towards rebalanced rsa-crt with short public exponent. Cryptology ePrint Archive: Report 2005/053 (2005). http://eprint.iacr.org/2005/053.

[Syv98]

Syverson, P. Weakly secret bit commitment applications to lotteries and fair exchange, 1998.

[TCG]

Trusted Computing Group. http://www.trustedcomputinggroup.org, http://www.trustedcomputinggroup.org.

[Tel06]

Tel, G. Gedistribueerd programmeren. Dictaat, Dept of Computer Science, Utrecht University, 2006.

[VAS03]

R Family of Tokens, 2003. VASCO. VASCO DIGIPASS°

[WD88]

W. Diffie, M. H. New directions in cryptografy. IEEE Transactions on Information Theory IT-22, 6 (1988), 644–654.


153

[Wie90]

Wiener, M. Cryptanalysis of short rsa secret exponents. IEEE transactions on Information Theory 36 (1990), 553–558.

[Wik]

Wikipedia. Soap. http://en.wikipedia.org/wiki/SOAP.

[Wil82]

Williams, H. A p + 1 method of factoring. Mathematics of Computation 39, 159 (1982), 225–234.

[Win03]

Windley, P. Digital id and egovernment.

[WY04]

Wright, R. N. and Yang, Z. Privacy-preserving bayesian network structure computation on distributed heterogeneous data. In proc. KDD ’04: Proceedings of the tenth ACM SIGKDD international conference on Knowledge discovery and data mining (New York, NY, USA, 2004), ACM Press, pp. 713–718.

[WYS06]

Wright, R. N., Yang, Z., and Subramaniam, H. Experimental analysis of a privacy-preserving scalar product protocol. In proc. International Journal of Computer Systems Science and Engineering (2006), vol. 21, CRL PUBLISHING LTD, pp. 47–52.

[Yao82]

Yao, A. Protocols for secure computations. Proceedings of the 23rd Annual IEEE Symposium on Foundations of Computer Science (1982), 160–164.

[YY06]

Young, A. and Yung, M. A space efficient backdoor in RSA and its applications. 128–143.

[Zim95]

Zimmermann, P. The official PGP user’s guide. MIT Press Cambridge, MA, USA, 1995.

[Zim06]

Zimmermann, P. Zrtp: Extensions to rtp for diffie-hellman key agreement for srtp, 2006. http://zfoneproject.com/docs/draft-zimmermann-avt-zrtp-02.html.

[ZMC05]

Zhan, J., Matwin, S., and Chang, L. W. Private mining of association rules. In proc. Intelligence and Security Informatics (2005), vol. 3495 of Lecture Notes in Computer Science, Springer, pp. 72–80.

154

Bibliografie

Index DigiD, 118 DigiPass, 116 Digital Rights Management (DRM), 52 Digitale identiteit, 112 Discovery, 64

passive attack, 87, 97 a priori algorithm, 91 A-nummer, 118 acoustic analysis, 42 active attack, 87, 97 Addressing, 64 AES ICM, 3 association rules, 89 Authenticated Key Exchange (AKE), 10

Eindige lichamen, 77 elektronische loterij, 101 Elektronische Overheid, 118 elliptische kromme, twist van, 141 elliptische krommen, 138 EM analysis, 42 Eventing, 66

binair eindige lichaam, 138 blokfunctie, 76 blokgrootte, 31 botsing, 75 branch prediction analysis (BPA), 43, 44 branch prediction unit (BPU), 43 branch target buffer (BTB), 43

Feistel-netwerk, 48 fingerprint, 30 Fortezza, 13 forward prediction, 78 foutinjectie, 40

chosen ciphertext attack, 97 Cipher Feedback mode, 31 commitment protocol, 108 Control, 66 Control Point, 63

gekozen-cijfertekst-validatieaanval, 35 GnuPG, 29 H-ronde, 81 Hashfuncties, 75 Hasse, stelling van, 138 HMAC, 4 HMQV, 15 homomorphic encryption, 88 horizontally partitioned, 85 hybride cipher, 29

data mining, 86 decryptieorakel, 33 Description, 65 Device, 63 Devices Profile for Web Serivces, 73 DeviceSecurity, 69 Differentiële cryptanalyse, 78 differentiële trace, 50 differential power analysis (DPA), 42, 48 Diffie–Hellman Signed, 11 sleutelprotocol, 10

ideal protocol, 87 Identificatie, 111 Identiteit, 112 Context afhankelijkheid, 114 Digitale, 112 Identity Certificate, 2 implementatie aanval, 40

155

156

Index

initialisatievector, 32 Internetbankieren, 114 inverse, 75 karakteristiek, 138 KEA+, 14 kernfunctie, 76 Key Exchange Algorithm (KEA), 12 L-ronde, 81 local loop, 1 loterij, 101 man-in-the-middle aanval, 11 MQV, 15 NSA, 12, 40, 42 One-Time Password, 116 One-way, 75 padding-regel, 76 PGP, 29 phishing, 121 priemlichaam, 138 privacy-preserving data mining, 85 pseudo random, 109 Pseudo-aanvallen, 78 Public Switched Telephone Network (PSTN), 1 puntcompressie, 139 random getallen, 108 Real-Time Transport Protocol (RTP), 5 reductiepolynoom, 138 RFC1149, 62 RPC, 62 secure multiparty computation, 87, 88 secure scalar product computation, 94 Security Ceremonies, 67 SecurityConsole, 69 SecurityID, 69 selectiefunctie, 49 semantically secure, 88 Services, 63 sessiesleutel, 30 Session Initiation Protocol (SIP), 5 SETUP, 137, 142 Short Authentication String (SAS), 6 side channel, 40

side channel attack, 40 acoustic analysis, 42 branch prediction analysis, 43, 44 differentiële aanval, 41 differential power analysis, 42, 48 EM analysis, 42 simpele aanval, 41 simple power analysis, 47 thermal imaging, 42 timing analysis, 42 Signed Diffie–Hellman, 11 simple power analysis (SPA), 47 Simple Service Discovery Protocol, 65 SKIPJACK, 12 sleuteluitwisseling, 9 protocollen, 10 veiligheidseisen, 9 SMASH, 75 SMASH-256, 79 SMASH-512, 80 SMASH-ORDy, 82 SOAP, 62, 65, 66 SOFI-nummer, 118 SSL, 115 Sterk botsingsvrij, 75 sterke SETUP, 142 superincreasing sequence, 97 TEMPEST, 42 thermal imaging, 42 timing analysis, 42 true random, 109 tweede inverse, 75 uitbreidingsgraad, 138 uniforme distributie, 104 Unknown Key Share (UKS) aanval, 13 UPnPTM , 61 van Eck radiation, 42 VASCO DigiPass, 116 vertically partitioned data, 85 Voice Over IP (VOIP), 4 voorspellen, 103, 104 web of trust, 31 Yao’s general method, 88 Zwak botsingsvrij, 75

Cryptografie aan het Werk

Recommend Documents