• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Breakfast Bytes
  3. Circuits and Systems for Security and Privacy
Paul McLellan
Paul McLellan

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
security
side channel attacks
encryption
puf
crc press
random number
physically unclonable functions

Circuits and Systems for Security and Privacy

9 Feb 2017 • 6 minute read

 breakfast bytes logocircuits and systems for security and privacyOne of the perks of writing this blog is that I get offered review copies of interesting books related to the semiconductor industry. It is hard to go a day without hearing about IoT security issues (and I write about it regularly, most recently in Video Cameras: No Service for You). So I was interested in taking a look at Circuits and Systems for Security and Privacy, edited by Farhana Sheikh and Leonel Sousa.

The opening chapters of the book are an overview of cryptography for someone who knows little about it, starting with the mathematics of cryptography from elementary probability theory—all the way up to elliptic curve cryptography. This is followed by chapters on Block Ciphers, Secure Hashing, and Public Key Cryptography. If you are starting from scratch, these chapters are a good introduction. (I'm not sure, however, why stream ciphers don't get a mention.)

Books like this usually look at cryptography as a software problem, with such topics as "how to program AES" (advice: don't even think about not using a library routine, any more than you'd write your own Verilog simulator). Increasingly, though, there is acceptance of the trend that good security depends on building up trust, starting from the hardware. Complexity is the enemy of security, so having a simple hardware base to look after the keys, for example, is the way to go. But hardware also can do some things that software cannot—in particular, it can generate true random numbers from noise.

Also, any attempt to analyze the vulnerabilities of software algorithms must consider more than the software in the analysis—because typically, attacking the hardware on which the software runs is one of the weaknesses that must be considered. (In fact, at EDPS this year, some of these attacks were actually demonstrated, as I wrote about in Anything Beats Attacking the Crypto Directly. That is covered precisely in the final three chapters of the book.)

  • Physically Unclonable Functions: A Window into CMOS Process Variations
  • Random Number Generators for Cryptography
  • Side Channel Attacks

Physically Unclonable Functions

Physically Unclonable Functions, or PUFs. Although there are other possible implementations using other concepts (such as electrical noise), in the silicon world PUFs use random process generation to ensure that each chip ends up with a different function. I do love one understatement in the introduction to the chapter that "the manufacturing process is extremely complicated especially in the sub-45nm design space."

The idea is to end up with a structure on silicon that is easy to evaluate on each chip (so the encryption is efficient) but is impossible to predict how each chip will behave; for example, by analyzing the netlist or the layout. It is also important that it is impossible to clone, in the sense that each chip is different, due to manufacturing variation. You thus have a set of chips that essentially behave randomly, but each chip always behaves the same way. In practice, care must be taken about this because, for example, temperature and aging can affect process generation.

The chapter goes into various ways of implementing PUFs, from using subthreshold arbiters to using SRAM. The chapter is a little unnecessarily long due to adding a lot of content on how to implement a CMOS circuit, which I would expect anyone reading to either know or expect to learn from a book on semiconductor implementation, but there is a lot of content. It is a chapter that is over 50 pages long.

Random Number Generators

The problem is this: implementation of encryption requires truly random numbers, typically not just a small number of them but a continuous stream of them.

Software, however, is fundamentally deterministic. It is not hard to produce pseudo-random numbers—numbers that look random and pass tests (such as spectral analysis for randomness). But if you know the algorithm? When given one number, you can work out the next. Sure, you can add another level of randomness by folding in more data (such as the time of day or adding clever computations), but without doing a lot of analysis, this risks making things less random and introducing new vulnerabilities. The first part of the chapter talks mostly about these pseudo-random number generators. If you want to get told more than you want to know about this topic, Knuth devotes the entire second volume of his series of tomes on computer science to pseudo-random number generators and how to analyze them for randomness.

With hardware, however (in particular, semiconductors), it is possible to add true randomness, using sources of entropy from the physical world. Usually, when we design a circuit, we are careful to avoid anything where we are not certain what value will be output. These are known as true random number generators (TRNG). Again, as with PUFs, they can use various manufacturing variation to ensure that the sequence of random number is not deterministic.

Side Channel Attacks

The last chapter is on side-channel effects. I wrote about side-channel effects after the day on security at EDPS last year, where not only were they discussed but they were demonstrated. In the chip world, perhaps the most well known is differential analysis, which involves looking at the power consumed by the chip on each clock cycle and using that to deduce bits of the key. See my post Anything Beats Attacking the Crypto Directly.

Rowhammer

Because the book does not mention rowhammer, I'm guessing that it went to press before information about this became public. As it turns out, modern dynamic random-access memory (DRAM) is so dense that under some circumstances, the contents of one memory row can affect nearby rows that were not accessed. Doing this requires special patterns that cycle rapidly and repeatedly access one row. It sounds unpromising, but in fact, this has been demonstrated (and perhaps used) to get root privilege on targeted systems, so it is a real vulnerability. I suppose this is classified as a side-channel attack because it is not attacking the crypto directly.

You can defend against this effect using either hardware or pseudo-hardware approaches that ensure that a row cannot get "hammered" more than a certain number of times without a DRAM refresh cycle (which defeats the attack). This is known as Target Row Refresh (TRR) or Pseudo Target Row Refresh (pTRR). It can also be defeated by monitoring the cache. Because the exploit depends on hammering the DRAM itself, a huge number of cache misses are also required to ensure that the DRAM gets accessed, so monitoring cache misses for very high peaks or unusual behavior can also catch the attempt.

It turns out that in his keynote at the RISC-V workshop, Google's Eric Grosse told everyone that rowhammer had been known by the memory companies for two years. But they didn't think it was a real vulnerability because they didn't see how anyone could exploit it, so they never told anyone. Not telling anyone is a really bad way to deal with a known vulnerability.

Buy the Book

You can purchase the book on Amazon or directly from the publisher. It is also available in an ebook version for about $50 less. Even so, for $125.97, it's hardly an impulse buy for a long plane flight.

Also available from the publisher, you can rent the ebook version, starting at $81 for six months.