An Example Scientific Experiment in Cryptography

For an example of cybersecurity science in cryptography, look at the paper “SDDR: light-weight, secure mobile encounters” by Lentz et al. (2014). In the following abstract, you can see that an implied hypothesis is that SDDR, the authors’ new protocol for discovery of nearby devices, is provably correct and at least as energy-efficient as other proven cryptographic protocols. These developers took a two-pronged approach in their evaluation with both formal proof of security and experimental results of its energy efficiency using a research prototype. This combined approach appeals to a wider audience than, say, a formal proof alone. Note that the abstract highlights “four orders of magnitude more efficient” in energy-efficiency and “only ~10% of the battery,” though readers must draw their own conclusions about the impressiveness of those results.

Abstract from an experiment of cybersecurity science in cryptography

Emerging mobile social apps use short-range radios to discover nearby devices and users. The device discovery protocol used by these apps must be highly energy-efficient since it runs frequently in the background. Also, a good protocol must enable secure communication (both during and after a period of device co-location), preserve user privacy (users must not be tracked by unauthorized third parties), while providing selective linkability (users can recognize friends when strangers cannot) and efficient silent revocation (users can permanently or temporarily cloak themselves from certain friends, unilaterally and without re-keying their entire friend set).

We introduce SDDR (Secure Device Discovery and Recognition), a protocol that provides secure encounters and satisfies all of the privacy requirements while remaining highly energy-efficient. We formally prove the correctness of SDDR, present a prototype implementation over Bluetooth, and show how existing frameworks, such as Haggle, can directly use SDDR. Our results show that the SDDR implementation, run continuously over a day, uses only ∼10% of the battery capacity of a typical smartphone. This level of energy consumption is four orders of magnitude more efficient than prior cryptographic protocols with proven security, and one order of magnitude more efficient than prior (unproven) protocols designed specifically for energy-constrained devices.

As a practitioner, how would you apply these research results or ideas if you saw this paper online or heard about it from a colleague? If you develop smartphone applications, you might be interested in incorporating this protocol into your own product. Thankfully, all of the research prototype code for SDDR is available on GitHub. Or, you may have a solution of your own already and wish to compare how your algorithm compares to SDDR. Or maybe you’re curious or skeptical and want to replicate or extend the experimental results from this paper.

Experimental Evaluation of Cryptographic Designs and Implementation

One of the most common experimental evaluations in cryptography is of the performance of cryptographic algorithms. Cryptographers and practitioners compare algorithms in order to understand the algorithms’ strengths, weaknesses, and features. Those results inform future cryptographic design and inform the choice of algorithm to use in a new cybersecurity solution. Figure 7-1 illustrates a comparison of throughput for six cryptographic algorithms. Other performance metrics in cryptography commonly include encryption time and power consumption. These results come from running the algorithm and measuring the relevant metric, perhaps with different input file sizes. It is critically important to report the type of hardware used for the experiment in these studies since hardware specifications, especially processors and memory, strongly influence cryptographic performance.

Figure 7-1. Throughput (megabytes/second) of six symmetric encryption algorithms from “Evaluating The Performance of Symmetric Encryption Algorithms” (2010)

There is value in experimental evaluation for cybersecurity implementations beyond a comparison of the algorithms themselves. Experimental evaluation of implementations and cryptography in practice are also possible. One could design an experiment to measure the lifetime of cryptographic keys in memory for different operating systems, or the usability of encryption features in email (see the case study in Chapter 11).

There are many other ways to evaluate cryptographic designs and implementations. Cryptanalysis attacks are used to evaluate the mathematical construction and practical implementation of cryptographic algorithms. Here are some common cryptographic attacks that can be used in experimentation:

Known-plaintext attack

The attacker obtains the ciphertext of a given plaintext.

Chosen-ciphertext attack

The attacker obtains the plaintexts of arbitrary ciphertexts of his own choosing.

Chosen-plaintext attack

The attacker obtains the ciphertexts of arbitrary plaintexts of her own choosing.

Brute-force attack

The attacker calculates every possible combination of input (e.g., passwords or keys) and tests to see if each is correct.

Man-in-the-middle attack

The attacker secretly relays and possibly alters the communication between two parties who believe they are communicating directly with each other.

Cryptography is an answer to the problem of data protection. If you were given a new cybersecurity solution, say software for full disk encryption, how would you evaluate its effectiveness at doing what it claims and how would you validate whether you were any more secure from using it? These questions start to blur the line between cryptography and software assurance, not to mention risk management.

If you implement or test cryptography, keep several things in mind. First, in cryptography, Kerckhoffs’s principle states that a cryptosystem should be secure even if everything about the system (except the key) is public knowledge. One implication of this principle is that cryptographic algorithms should be subject to peer review, not kept secret. Second, because cryptography implementers are often not cryptographers themselves, errors and shortcuts in implementation can weaken the cryptography.¹ Third, you should also pay attention to all the details of the protocol specification and check the assumptions attached to the cryptographic and protocol designs. Security assumptions are discussed in the next section. Finally, be aware that we are rarely sure if cryptography is completely secure. Acceptance of cryptography generally comes from long periods of failed attacks, and experimentation can uncover such cryptographic weaknesses.

Provably Secure Cryptography and Security Assumptions

In 1949, mathematician and father of information theory Claude Shannon wrote A Mathematical Theory of Cryptography and proved the perfect secrecy of the one-time pad. This notion of perfect secrecy means that the ciphertext leaks no information about the plaintext. The phrase perfect secrecy requires some explanation. Information theory is a collection of mathematical theories about the methods for coding, transmitting, storing, retrieving, and decoding information. Perfect secrecy is an information theoretic notion of security, which means that you can use mathematical theories to prove it.

As a practitioner, it is important to understand that provable security in information theory and cryptography is not an absolute statement of security. Security proofs are conditional and are not absolute guarantees of security. Security is guaranteed only as long as the underlying assumptions hold. Provable security is incredibly important because it brings a quantitative nature to security. This enables protocol designers to know precisely how much security they gets with the protocol.

Take SSH as an example. In 2002, three researchers conducted the first formal security analysis of the SSH Binary Packet Protocol (BPP) using the provable security approach.² Yet, other researchers later showed an attack on SSH BPP because the proven security model made some assumptions about the real-world system executing the decryption.³ A very good research question comes from this example: how do we know that “fixing” SSH actually improves security? TLS/SSL, too, has been studied, and by 2013 there were papers showing that most unaltered full TLS ciphersuites offer a secure channel. The important words are most, unaltered, and full. No security analysis has yet shown that TLS is secure in all situations.

A security model is the combination of a trust and threat models that address the set of perceived risks. Every cybersecurity design needs a security model. You cannot talk about the security of a system in a vacuum without also talking about the threats, risks, and assumptions of trust. The work lies in determining what assumptions to include in a security model and how close the theoretical model is to the practical implementation to capture the significant attack vectors. To get you started thinking of assumptions on your own, here are a few potential assumptions about threats or attackers’ technical abilities that could be made for a particular situation or environment:

• The adversary can read and modify all communications.

• The adversary has the ability to generate messages in a communication channel.

• The adversary has no ability to tamper with communication between the honest parties.

• The adversary has the ability to spoof its identity.

• The adversary has the ability to leak from each key a few bits at a time.

• The adversary does not have access to the master key.

• The adversary has the ability to predict operations costs.

• The adversary has unlimited computing power.

• The adversary can mount login attempts from thousands of unique IP addresses.

• The adversary cannot physically track the mobile users.

Whenever you make a security claim, also describe any and all assumptions you make about the threat. It is disingenuous to assume an all-powerful adversary or to underestimate the capabilities of possible adversaries. In the next section we will talk about the Internet of Things (IoT), where we might assume that you are designing the security for smart clothing like a shirt with movement sensors woven into the fabric. Here is one example adversarial model for that situation:

We assume that the adversary is interested in detecting a target’s movement at all times, thereby violating a user’s expected privacy. We assume that the adversary does not have physical access to his target’s shirt. We assume that the adversary can purchase any number of identical shirts to study. We assume that any other shirt may be corrupted and turned into a malicious item controlled by the adversary. We assume that the adversary has the ability to infer all of the IoT items that belong together or to the same user.

This collection of assumptions bounds what we explicitly believe the adversary can and cannot do. The model usually contains only those motivations, capabilities, or limitations of the adversary pertinent to the security offered by the proposed solution. You might go on to suggest that the shirt needs SSL security because you can construct an attack that would otherwise succeed given the stated adversarial model.

Not only do attackers target cryptographic implementations, they also target the written and unwritten assumptions. Note that security models are not limited to cryptography. It is quite common for cybersecurity papers to include an entire section on the threat model used in the paper. The threat model narrows the scope of the scenario and may also limit the applicability of the attack or defense being presented. These can be very specific statements, such as “we assume that the adversary does not have any privileged access on any of the key network entities such as servers and switches, so she is unable to place herself in the middle of the stream and conduct man-in-the-middle attacks.”

A well-defined security model benefits both the investigator conducting the assessment and the consumer of the final assessment. The model bounds the experiment and allows you to focus on a confined problem. It also establishes relevancy for the end user or consumer of your product.

Cryptographic Security and the Internet of Things

The proliferation of Internet-enabled devices has taken off more quickly than security measures for them. RSA Conference is an annual information security event with a strong emphasis on cryptography. This is one of the largest events in the industry, with around 33,000 attendees and more than 490 sessions in 2015. Presentations follow industry trends, and there has been a clear rise recently in talks on the Internet of Things (IoT). Kaspersky Labs summarized the trend in 2015 as the “Internet of Crappy Things” highlighting a string of new attacks on home automation and other consumer devices.

Small resource-constrained devices such as insulin pumps require algorithms that respect their computing power, memory requirements, and physical size. In a world of desktops, laptops, and even smartphones, we could implement RSA, AES, and other mainstream algorithms with an acceptable burden on the device. But what about a smartcard, smart meter, medical implant, or soil sensor? What you can fit on the device and what the device needs are very different. IoT devices need efficient, lightweight cryptographic implementations that are also trustworthy. There are at least 24 lightweight block ciphers today designed with these constraints in mind. The National Security Agency even proposed two families of lightweight block ciphers called Simon (optimized for hardware) and Speck (optimized for software).⁴ You can find a list of lightweight ciphers and their technical features (e.g., block size) on the CryptoLUX Wiki.

Some have proposed offloading cryptographic functions in resource-constrained devices. A dedicated microcontroller might increase performance and reduce the load on the main CPU. It might also be possible to outsource crypto to a service on another device, as long as certain assurances were made.

Experimentation in cybersecurity science can be used to measure and evaluate design choices for a specific device or class of devices. Say you are investing in a home automation system and want to add tiny soil moisture sensors that alert you when to water your plants. How would you decide how much wireless security was necessary, and whether the sensors could handle it? Deciding on the amount of security takes us back to the discussion in the previous section about threat models and assumptions. You must think about the different security threats and their associated likelihood. For example, do you care about physical attacks like node capture, impersonation attacks, denial-of-service attacks, replay attacks, or spoofing attacks? If you do care, what is the likelihood of them, and what is the cost of damage if any occur? We’ve just outlined a risk analysis that isn’t very technical but is nonetheless critical. On the technical side, how could you also determine how well the sensors could even perform the desired level of cryptography? These technical considerations are reflected in the case study in the next section.

Another example of IoT devices to consider is smart utility sensors such as water and electric meters. These devices are being offered (sometimes mandated) for both consumers and businesses. Smart meters effectively increase the attack surface because the devices are networked together or back to the provider. Today, consumers have little choice but to treat such devices as black boxes without knowledge of how they work. Experimentation and evaluation with the scientific method will allow users to determine the cybersecurity assurances and risks associated with smart meters.

Case Study: Evaluating Composable Security

How to Find More Information

Research in applied cryptography is presented at a large number of mathematics and cybersecurity conferences, including the USENIX Security Symposium, the International Conference on Applied Cryptography and Network Security (ACNS), and the International Cryptology Conference (CRYPTO). Likewise, research and experimental results appear in an assortment of journals and magazines, notably the Journal of Cryptology and IEEE Transactions on Information Forensics and Security. The Cryptology ePrint Archive also provides an electronic archive of new results and recent research cryptography.

Conclusion

In this chapter, we looked at how to use the scientific method to evaluate the design and application of cryptography. The key takeaways are:

• One of the most common experimental evaluations in cryptography is the performance of cryptographic algorithms, including encryption time and power consumption.

• Provably secure cryptography and security proofs are conditional and are not absolute guarantees of security. Security is guaranteed only as long as the underlying assumptions hold.

• A security model is the combination of a trust and threat models that address the set of perceived risks. Every cybersecurity design needs a security model.

• Scientific evaluation of cryptographic algorithms is important in resource-constrained IoT devices.

• The evaluation of composable security and emergent properties remains an open problem. We looked at a hypothetical experiment to test secure communications in IoT networks.

References

• Ran Canetti. Universally Composable Security: A New Paradigm for Cryptographic Protocols, Cryptology ePrint Archive, Report 2000/067, (July 16, 2013)

• Bruce Schneier and Niels Ferguson. Cryptography Engineering: Design Principles and Practical Applications (Indianapolis, IN: Wiley, 2010)

• Al Sweigart. Hacking Secret Ciphers with Python (Charleston, SC: CreateSpace Independent Publishing, 2013)