Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Hardware support for cryptography"]
N2["8.2 Caches and leakage"]
N3["8.3 Secure elements"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Hardware support for cryptography"]
N2["8.2 Caches and leakage"]
N3["8.3 Secure elements"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Hardware support for cryptography]
|
v
[8.2 Caches and leakage]
|
v
[8.3 Secure elements]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) describe how processors accelerate cryptography; (2) explain caches as a source of leakage; (3) evaluate secure elements for storing meter keys.
8.1 Hardware support for cryptography
Modern processors include instructions that accelerate AES and SHA-2 directly in hardware, which makes encryption fast and also helps resist timing leaks, because the hardware executes in constant time regardless of key values. Aiyana compares the server processors at Ridgeway, which have such instructions, with the small microcontrollers in meters, which may not. On a microcontroller, software AES must be written carefully to avoid table lookups that depend on secret data. This architectural detail affects which algorithms Ridgeway selects for meters and why it prefers vendors whose libraries document constant-time behaviour.
8.2 Caches and leakage
Caches make memory access faster by keeping recently used data close to the processor. Because access time depends on whether data is cached, a program whose memory accesses depend on secrets can leak those secrets to another program sharing the cache. Classic table-based AES implementations had this weakness. Aiyana learns that this is why cloud servers isolate sensitive workloads and why hardware instructions replaced lookup tables. For Ridgeway's servers, she recommends running the key service on dedicated hosts rather than shared virtual machines, a cost judged worthwhile for the most sensitive keys.
8.3 Secure elements
A secure element is a small tamper-resistant chip that stores keys and performs cryptographic operations internally, so the key never appears in the meter's main memory. It resists probing and side-channel attacks better than a general microcontroller. Aiyana compares three meter designs: key in flash memory, key in a protected region of the microcontroller, and key inside a secure element. The secure element costs more per meter but means that opening one meter and dumping its memory does not reveal its key. She records the trade-off and the residual risk that remains even with tamper resistance.
Worked example
Aiyana recommends secure elements for meter keys, hardware AES on servers, and dedicated hosts for the key service, with costs and residual risks recorded.
Synthetic case. Meter designs and costs are invented.
Errors and limits
Tamper resistance raises attacker cost but is not absolute. Hardware acceleration does not fix misuse such as nonce reuse.
Exercises
- EX022 — Hardware AES benefit. Name two benefits of hardware AES instructions.
Show marking criteria
Rubric: 3 = speed and constant-time execution resisting timing leaks;; 2 = one;; 1 = vague;; 0 = none. - EX023 — Cache leak. How can a cache leak secrets?
Show marking criteria
Rubric: 3 = access time depends on cached data; secret-dependent accesses reveal keys to a co-resident program;; 2 = timing mentioned;; 1 = no leak;; 0 = none. - EX024 — Secure element value. What does a secure element prevent compared with keys in flash?
Show marking criteria
Rubric: 3 = dumping memory from one opened meter does not reveal its key;; 2 = protects key;; 1 = encrypts data;; 0 = none.
Synthesis
Architecture shapes cryptographic security: hardware instructions, cache behaviour and secure elements decide how well keys survive in real devices.
Continue studying — chapter 08 of 50
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →