amounts of entropy.This usually means monitoring keystrokes and mouse movement and the interaction with various peripheral devices,such as hard disks. Entropy collected in this way is a type of true random number generator (TRNG),but the approach is not reliable enough to use directly.For example,you might need to generate a 4.09-bit key,but the system might have ony a coupe of hundreds of bits of entropy avail- able.If there are no reliable external events to collect enough entropy,the system might stall. For this reason,in practice we rely on pseudorandom number generators(PRNGs),which use small amounts of true random data to get them going.This process is known as seeding. From the seed,PRNGs produce unlimited amounts of pseudorandom data on demand. General-purpose PRNGs are often used in programming,but they are not appropriate for cryptography,even if their output is statistically seemingly random.Cryptographic pseudo- random number generators(CPRNGs)are PRNGs that are also unpredictable.This attribute is crucial for security;an adversary mustn't be able to reverse-engineer the internal state of a CPRNG by observing its output. Protocols Cryptographic primitives such as encryption and hashing algorithms are seldom useful by themselves.We combine them into schemes and protocols so that we can satisfy complex se- curity requirements.To illustrate how we might do that,let's consider a simplistic crypto- graphic protocol that allows Alice and Bob to communicate securely.We'll aim for all three main requirements:confidentiality,integrity,and authentication. Let's assume that our protocol allows exchange of an arbitrary number of messages.Because symmetric encryption is very good at encrypting bulk data,we might selectou favorite al- gorithm to use for this purpose,say,AES.With AES,Alice and Bob can exchange secure messages,and Mallory won't be able to recover the contents.But that's not quite enough because Mallory can do other things,for example,modify the messages without being de- tected.To fix this problem,we can calculate a MAC of each message using a hashing key known only to Alice and Bob.When we send a message,we send along the MAC as well Now,Mallory can't modify the messages any longer.However,she could still drop or replay arbitrary messages.To deal with this,we extend our protocol to assign a sequence number to each message;crucially,we make the sequences part of the MAC calculation.If we see a gap in the sequence numbers,then we know that there's a message missing.If we see a se- quence number duplicate,we detect a replay attack.For best results,we should also use a special message to mark the end of the conversation.Without such a message,Mallory would be able to end(truncate)the conversation undetected. With all of these measures in place,the best Mallory can do is prevent Alice and Bob from talking to one another.There's nothing we can do about that. Protocols
amounts of entropy. is usually means monitoring keystrokes and mouse movement and the interaction with various peripheral devices, such as hard disks. Entropy collected in this way is a type of true random number generator (TRNG), but the approach is not reliable enough to use directly. For example, you might need to generate a 4,096-bit key, but the system might have only a couple of hundreds of bits of entropy available. If there are no reliable external events to collect enough entropy, the system might stall. For this reason, in practice we rely on pseudorandom number generators (PRNGs), which use small amounts of true random data to get them going. is process is known as seeding. From the seed, PRNGs produce unlimited amounts of pseudorandom data on demand. General-purpose PRNGs are often used in programming, but they are not appropriate for cryptography, even if their output is statistically seemingly random. Cryptographic pseudorandom number generators (CPRNGs) are PRNGs that are also unpredictable. is attribute is crucial for security; an adversary mustn’t be able to reverse-engineer the internal state of a CPRNG by observing its output. Protocols Cryptographic primitives such as encryption and hashing algorithms are seldom useful by themselves. We combine them into schemes and protocols so that we can satisfy complex security requirements. To illustrate how we might do that, let’s consider a simplistic cryptographic protocol that allows Alice and Bob to communicate securely. We’ll aim for all three main requirements: confidentiality, integrity, and authentication. Let’s assume that our protocol allows exchange of an arbitrary number of messages. Because symmetric encryption is very good at encrypting bulk data, we might select our favorite algorithm to use for this purpose, say, AES. With AES, Alice and Bob can exchange secure messages, and Mallory won’t be able to recover the contents. But that’s not quite enough, because Mallory can do other things, for example, modify the messages without being detected. To fix this problem, we can calculate a MAC of each message using a hashing key known only to Alice and Bob. When we send a message, we send along the MAC as well. Now, Mallory can’t modify the messages any longer. However, she could still drop or replay arbitrary messages. To deal with this, we extend our protocol to assign a sequence number to each message; crucially, we make the sequences part of the MAC calculation. If we see a gap in the sequence numbers, then we know that there’s a message missing. If we see a sequence number duplicate, we detect a replay attack. For best results, we should also use a special message to mark the end of the conversation. Without such a message, Mallory would be able to end (truncate) the conversation undetected. With all of these measures in place, the best Mallory can do is prevent Alice and Bob from talking to one another. ere’s nothing we can do about that. Protocols 15
So far,so good,but we're still missing a big piece:how are Alice and Bob going to negotiate the two needed keys(one for encryption and the other for integrity validation)in the pres- ence of Mallory?We can solve this problem by adding two additional steps to the protocol. First,we use public-key cryptography to authenticate each party at the beginning of the conversation.For example,Alice could generate a random number and ask Bob to sign it to prove that it's really him.Bob could ask Alice to do the same With authentication out of the way,we can use a key-exchange scheme to negotiate encryp- tion keys securely.For example,Alice could generate all the keys and send them to Bob by encrypting them with his public key:this is how the RSA key exchange works.Alternatively. we could have also used a protocol known as Diffie-Hellman (DH)key exchange for this purpose.The latter is slower,but it has better security properties In the end,we ended up with a protocol that (1)starts with a handshake phase that includes authentication and key exchange,(2)follows with the data exchange phase with confiden- tiality and integrity,and(3)ends with a shutdown sequence.At a high level,our protocol is similar to the work done by SSL and TLS. Attacking Cryptography Complex systems can usually be attacked in a variety of ways,and cryptography is no ex- ception.First,you can attack the cryptographic primitives themselves.If a key is small,the adversary can use brute force to recover it.Such attacks usually require a lo of processing power as well as time.It's easier(for the attacker)if the used primitive has known vulnera- bilities,in which case he can use analytic attacks to achieve the goal faster. Cryptographic primitives are generally very well understood,because they are relatively straightforward and do only one thing.Schemes are often easier to attack because they in- troduce additional complexity.In some cases,even ryptographers argue about the right way to perform certain operations.But both are relatively safe compared to protocols, which tend to introduce far more complexity and have a much larger attack surface. Then,there are attacks against protocol implementation;in other words,exploitation of soft ware bugs.For example,most cryptographic libraries are written in low-level languages such as C(and even assembly,for performance reasons),which make it very easy to intro- duce catastrophic programming errors.Even in the absence of bugs,sometimes great skill is needed to implement the primitives,schemes,and protocols in such a way that they can't be abused.For example,naive implementations of certain algorithms can be exploited in tim- ing attacks,in which the attacker breaks encryption by observing how long certain opera- tions take. It is also common that programmers with little experience in cryptography nevertheless at- tempt to implement-and even design-cryptographic protocols and schemes,with pre- dictably insecure results Chapter 1:SSL,TLS,and Cryptography
So far, so good, but we’re still missing a big piece: how are Alice and Bob going to negotiate the two needed keys (one for encryption and the other for integrity validation) in the presence of Mallory? We can solve this problem by adding two additional steps to the protocol. First, we use public-key cryptography to authenticate each party at the beginning of the conversation. For example, Alice could generate a random number and ask Bob to sign it to prove that it’s really him. Bob could ask Alice to do the same. With authentication out of the way, we can use a key-exchange scheme to negotiate encryption keys securely. For example, Alice could generate all the keys and send them to Bob by encrypting them with his public key; this is how the RSA key exchange works. Alternatively, we could have also used a protocol known as Diffie-Hellman (DH) key exchange for this purpose. e latter is slower, but it has better security properties. In the end, we ended up with a protocol that (1) starts with a handshake phase that includes authentication and key exchange, (2) follows with the data exchange phase with confidentiality and integrity, and (3) ends with a shutdown sequence. At a high level, our protocol is similar to the work done by SSL and TLS. Attacking Cryptography Complex systems can usually be attacked in a variety of ways, and cryptography is no exception. First, you can attack the cryptographic primitives themselves. If a key is small, the adversary can use brute force to recover it. Such attacks usually require a lot of processing power as well as time. It’s easier (for the attacker) if the used primitive has known vulnerabilities, in which case he can use analytic attacks to achieve the goal faster. Cryptographic primitives are generally very well understood, because they are relatively straightforward and do only one thing. Schemes are often easier to attack because they introduce additional complexity. In some cases, even cryptographers argue about the right way to perform certain operations. But both are relatively safe compared to protocols, which tend to introduce far more complexity and have a much larger attack surface. en, there are attacks against protocol implementation; in other words, exploitation of software bugs. For example, most cryptographic libraries are written in low-level languages such as C (and even assembly, for performance reasons), which make it very easy to introduce catastrophic programming errors. Even in the absence of bugs, sometimes great skill is needed to implement the primitives, schemes, and protocols in such a way that they can’t be abused. For example, naïve implementations of certain algorithms can be exploited in timing attacks, in which the attacker breaks encryption by observing how long certain operations take. It is also common that programmers with little experience in cryptography nevertheless attempt to implement—and even design—cryptographic protocols and schemes, with predictably insecure results. 16 Chapter 1: SSL, TLS, and Cryptography
For this reason,it is often said that cryptography is bypassed,not attacked.What this means is that the primitives are solid,but the rest of the soft ware ecosystem isn't.Further,the keys are an attractive target:why spend months to brute-force a key when it might be much easi- er to break into a server to obtain it?Many cryptographic failures can be prevented by fol- lowing simple rules such as these:(1)use well-established protocols and never design your own schemes;(2)use high-level libraries and never write code that deals with cryptography directly;and(3)use well-established primitives with sufficiently strong key sizes Measuring Strength We measure the strength of cryptography using the number of operations that need to be performed to break a particular primitive,presented as bits of security.Deploying with strong key sizes is the easiest thing to get right,and the rules are simple:128 bits of security (2128 operations)is sufficient for most deployments;use 256 bits if you need very long-term security or a big safety margin. Note The strength of symmetric cryptographic operations increases exponentially as more bits are added.This means that increasing key size by one bit makes it twice as strong. In practice,the situation is somewhat more complicated,because not all operations are equivalent in terms of security.As a result,different bit values are used for symmetric opera- tions,asymmetric operations,elliptic curve cryptography,and so on.You can use the infor- mation in Table 1.2,"Security levels and equivalent strength in bits,adapted from ECRYPT2 (2012)"to convert from one size to another. Table 1.2.Security levels and equivalent strength in bits,adapted from ECRYPT2(2012) #Protection Sym- Asym- DH Elliptic Hash metric metric Curve 1 Attacks in real time by individuals 32 2 Very short-term protection against small organizations 64 816 816 128 128 3 Shor-moaganst 2 1,008 1,008 14 144 4 Very short-term protection against agencies 80 1.248 1248 160 160 5 Short-term protection(10 years) 96 1,776 1,776 6 Medium-term protection (20 vears) 112 2432 2.432 224 224 Long-term(30 years) 128 3.248 3.248 256 256 8 Long-term protection and increased defense from quan- 256 15,424 15.424 512 512 tum computers Measuring Strength 17
For this reason, it is often said that cryptography is bypassed, not attacked. What this means is that the primitives are solid, but the rest of the software ecosystem isn’t. Further, the keys are an attractive target: why spend months to brute-force a key when it might be much easier to break into a server to obtain it? Many cryptographic failures can be prevented by following simple rules such as these: (1) use well-established protocols and never design your own schemes; (2) use high-level libraries and never write code that deals with cryptography directly; and (3) use well-established primitives with sufficiently strong key sizes. Measuring Strength We measure the strength of cryptography using the number of operations that need to be performed to break a particular primitive, presented as bits of security. Deploying with strong key sizes is the easiest thing to get right, and the rules are simple: 128 bits of security (2128 operations) is sufficient for most deployments; use 256 bits if you need very long-term security or a big safety margin. Note e strength of symmetric cryptographic operations increases exponentially as more bits are added. is means that increasing key size by one bit makes it twice as strong. In practice, the situation is somewhat more complicated, because not all operations are equivalent in terms of security. As a result, different bit values are used for symmetric operations, asymmetric operations, elliptic curve cryptography, and so on. You can use the information in Table 1.2, “Security levels and equivalent strength in bits, adapted from ECRYPT2 (2012)” to convert from one size to another. Table 1.2. Security levels and equivalent strength in bits, adapted from ECRYPT2 (2012) # Protection Symmetric Asymmetric DH Elliptic Curve Hash 1 Attacks in real time by individuals 32 - - - - 2 Very short-term protection against small organizations 64 816 816 128 128 3 Short-term protection against medium organizations 72 1,008 1,008 144 144 4 Very short-term protection against agencies 80 1,248 1,248 160 160 5 Short-term protection (10 years) 96 1,776 1,776 192 192 6 Medium-term protection (20 years) 112 2,432 2,432 224 224 7 Long-term protection (30 years) 128 3,248 3,248 256 256 8 Long-term protection and increased defense from quantum computers 256 15,424 15,424 512 512 Measuring Strength 17
The data,which I adapted from a 2012 report on key and algorithm strength,6 shows rough mappings from bits of one type to bits of another,but it also defines strength in relation to attacker capabilities and time.Although we tend to discuss whether an asset is secure (as. suming now),in reality security is a function of time.The strength of encryption changes, because as time goes by computers get faster and cheaper.Security is also a function of re- sources.A key of a small size might be impossible for an individual to break,but doing so could be within the reach of an agency.For this reason,when discussing security it's more useful to ask questions such as"secure against whom?"and"secure for how long?" Note The strength of cryptography can't be measured accurately,which is why ou will find many different recommendations.Most of them are very similar,with smal differences.In my experience,ENISA (the European Union Agency for Network and Information Security)provides useful high-level documents that offer clear guid- ancel7 at various levels.18 To view and compare other recommendations,visit keylength.com. Although the previous table provides a lot of useful information,you might find it difficult Table 1.3.Encryption strength mapping for commoy used key sizes Symmetric RSA/DSA/DH Elliptic curve crypto Hash 80 1.024 160 160 112 2,048 224 224 128 3.072 256 256 256 15,360 512 512 Man-in-the-Middle Attack Most attacks against transport-layer security come in the form of a man-in-the-middle (MITM)attack.What this means is that in addition to the two parties involved in a conver- sation there is a malicious party.If the attacker is just listening in on the conversation,were talking about a passive network attack.If the attacker is actively modifying the traffic or in- fluencing the conversation in some other way,were talking about an active network attack. CRYPT Yearly Keysi(Network of September ,Key Sizes and Param eters Renort (ENISA 29 0ctober 2013) 18D data (ENISA 4November 013 STpaic-tinokenagm -Part :General Revison 3(NIST,July 0) Chapter 1:SSL,TLS,and Cryptography
e data, which I adapted from a 2012 report on key and algorithm strength,16 shows rough mappings from bits of one type to bits of another, but it also defines strength in relation to attacker capabilities and time. Although we tend to discuss whether an asset is secure (assuming now), in reality security is a function of time. e strength of encryption changes, because as time goes by computers get faster and cheaper. Security is also a function of resources. A key of a small size might be impossible for an individual to break, but doing so could be within the reach of an agency. For this reason, when discussing security it’s more useful to ask questions such as “secure against whom?” and “secure for how long?” Note e strength of cryptography can’t be measured accurately, which is why you will find many different recommendations. Most of them are very similar, with small differences. In my experience, ENISA (the European Union Agency for Network and Information Security) provides useful high-level documents that offer clear guidance17 at various levels.18 To view and compare other recommendations, visit keylength.com. 19 Although the previous table provides a lot of useful information, you might find it difficult to use because the values don’t correspond to commonly used key sizes. In practice, you’ll find the following table more useful to convert from one set of bits to another:20 Table 1.3. Encryption strength mapping for commonly used key sizes Symmetric RSA / DSA / DH Elliptic curve crypto Hash 80 1,024 160 160 112 2,048 224 224 128 3,072 256 256 256 15,360 512 512 Man-in-the-Middle Attack Most attacks against transport-layer security come in the form of a man-in-the-middle (MITM) attack. What this means is that in addition to the two parties involved in a conversation there is a malicious party. If the attacker is just listening in on the conversation, we’re talking about a passive network attack. If the attacker is actively modifying the traffic or in- uencing the conversation in some other way, we’re talking about an active network attack. 16 ECRYPT2 Yearly Report on Algorithms and Keysizes (European Network of Excellence for Cryptology II, 30 September 2012) 17 Algorithms, Key Sizes and Parameters Report (ENISA, 29 October 2013) 18 Recommended cryptographic measures - Securing personal data (ENISA, 4 November 2013) 19 BlueKrypt: Cryptographic Key Length Recommendation (BlueKrypt, retrieved 4 June 2014) 20 NIST Special Publication 800-57: Recommendation for Key Management – Part 1: General, Revision 3 (NIST, July 2012) 18 Chapter 1: SSL, TLS, and Cryptography
Figure 1.6.Conceptual SSL/TLS threat model Attacks against users Attacks against servers Local MITM attacks (e.g over Wi-Fi network) Exposed link:14 hops,several thousand miles and several counri Gaining Access In many cases,attacks require proximity to the victim or the server or access to the commu- nication infrastructure.Whoever has access to the cables and intermediary communication nodes (e.g.,routers)can see the packets as they travel across the wire and interfere with them.Access can be obtained by tapping the cables,21 in collaboration with telecoms,22 or by hacking the equipment.23 Conceptually,the easiest way to execute a MITM attack is by joining a network and rerout- ing the victims'traffic through a malicious node.Wireless networks without authentication which so many people use these days,are particularly vulnerable,because anyone can join. Other ways to attack include interfering with the routing infrastructure for domain name resolution,IP address routing,and so on. ARP spoofing Address Resolution Protocol(ARP)is used on local networks to associate network MAC addresses24 with IP addresses.An attacker with access to the network can claim any IP address and effectively reroute traffic. 2The r n-a August 2013) 3 Photos of an NSA "upgrade"factory show Cisco router getting implant (Ars Technica,14 May 2014) 2 In this case,MAC standsor mediaassanique identifier assigned to networkingcards during manufacture. Man-in-the-Middle Attack 2
Figure 1.6. Conceptual SSL/TLS threat model Server User Local MITM attacks (e.g., over Wi-Fi network) DNS server hijacking and cache poisoning attacks Attacks against users DNS hijacking at registry and other routing attacks Exposed communication link: 14 hops, several thousand miles and several countries Attacks against servers Gaining Access In many cases, attacks require proximity to the victim or the server or access to the communication infrastructure. Whoever has access to the cables and intermediary communication nodes (e.g., routers) can see the packets as they travel across the wire and interfere with them. Access can be obtained by tapping the cables,21 in collaboration with telecoms,22 or by hacking the equipment.23 Conceptually, the easiest way to execute a MITM attack is by joining a network and rerouting the victims’ traffic through a malicious node. Wireless networks without authentication, which so many people use these days, are particularly vulnerable, because anyone can join. Other ways to attack include interfering with the routing infrastructure for domain name resolution, IP address routing, and so on. ARP spoofing Address Resolution Protocol (ARP) is used on local networks to associate network MAC addresses24 with IP addresses. An attacker with access to the network can claim any IP address and effectively reroute traffic. 21 The Creepy, Long-Standing Practice of Undersea Cable Tapping (The Atlantic, 16 July 2013) 22 New Details About NSA’s Collaborative Relationships With America’s Biggest Telecom Companies From Snowden Docs (Washington Post, 30 August 2013) 23 Photos of an NSA “upgrade” factory show Cisco router getting implant (Ars Technica, 14 May 2014) 24 In this case, MAC stands for media access control. It’s a unique identier assigned to networking cards during manufacture. Man-in-the-Middle Attack 19