Hardware tokens for user authentication need a secure and usable mechanism to lock them when not in use. The Pico academic project proposes an authentication token unlocked by the proximity of simpler wearable devices that provide shares of the token’s master key. This method, however, is vulnerable to a cold boot attack: an adversary who captures a running Pico could extract the master key from its RAM and steal all of the user’s credentials. We present a cryptographic countermeasure—bivariate secret sharing—that protects all the credentials except the one in use at that time, even if the token is captured while it is on. Remarkably, our key storage costs for the wearables that supply the cryptographic shares are very modest (256 bits) and remain constant even if the token holds thousands of credentials. Although bivariate secret sharing has been used before in slightly different ways, our scheme is leaner and more efficient and achieves a new property—cold boot protection. We validated the efficacy of our design by implementing it on a commercial Bluetooth Low Energy development board and measuring its latency and energy consumption. For reasonable choices of latency and security parameters, a standard CR2032 button-cell battery can power our prototype for 5–7 months, and we demonstrate a simple enhancement that could make the same battery last for over 9 months.

1. Low-cost Protection against Cold Boot Attacks for an
Authentication Token
Applied Cryptography and Network Security 2016
Ian Goldberg1 Graeme Jenkinson2 @gcjenkinson Frank Stajano2
2University of Waterloo (Canada)
2University of Cambridge (United Kingdon)
ACNS 2016-06-20

2. Pico: A usable and secure memory prosthesis (Stajano
2011)
MEMORYLESS, SCALABLE and SECURE
www.mypico.org
2 of 21

3. Pico’s benefits (Stajano 2011)
Usability
WORKS-FOR-ALL, FROM-ANYWHERE, NO-SEARCH,
NO-TYPING, CONTINUOUS
Security
NO-WEAK, NO-REUSE, NO-PHISHING,
NO-EAVESDROPPING, NO-KEYLOGGING, NO-SURFING,
NO-LINKAGE, LOSS/THEFT-RESITANCE
www.mypico.org
3 of 21

4. Loss/theft resistance
Picosiblings
1. Small devices you carry with you
2. Pico unlocks only in presence of
k-out-of-n Picosiblings
3. Picosibling shares construct full disk
encrytion (FDE) key
4 of 21

5. Picosibling protocol requirements
1. The Pico can ascertain the presence of any of its Picosiblings in
the vicinity
2. The Picosibling responds to its master Pico but to no other
3. When challenged, the Picosibling sends its k-out-of-n share to the
Pico, but in a way that doesn’t reveal it to an eavesdropper
4. An eavesdropper can detect the comms between the Pico and its
Picosiblings but not infer long-term pseudonyms
5. The Pico can detect and ignore old replayed messages
6. The Pico can detect and ignore relay attacks
5 of 21

6. Attacker model
1. Attacker can listen to the comms between Pico and Picosiblings
2. Attacker can send messages to Pico and Picosiblings
3. Attacker can capture and read out the contents of a Pico and
fewer than k Picosiblings
Concessions
▶ Secure at first use
▶ Defender has some low-cost tamper proofing facilities such as
those used in smartcards and phone SIMs in order to provide a
small amount of memory that the attacker can’t read
6 of 21

7. Cold boot attack (Halderman et al 2008)
Attacker model
Attacker wins if they can extract all
the credentials in plaintext, or use a
captured Pico to authenticate as its
owner.
Memory readout attack whilst
single FDE key is in memory
7 of 21

8. A new secret sharing scheme for authentication tokens
Partition Pico’s encrypted storage into many small bins, each holding a
few (ideally one) credential(s).
Hash of
service’s
identifier
Bin
identi-
fier
Encrypted credential Userid
H(IDGoogle) 0x1e {credGoogle,jane.doe}K(0x1e) jane.doe
H(IDAmazon) 0x75 {credAmazon,jane257}K(0x75) jane257
H(IDTwitter ) 0x57 {credTwitter,@jane}K(0x57) @jane
. . . . . . . . . . . .
H(IDExpedia) 0x1e {credExpedia,jane257}K(0x1e) jane257
H(IDTwitter ) 0x32 {credTwitter,@tattoophile}K(0x32) @tattoophile
8 of 21

9. Details...
Keying polynomial
The secret to be shared across the Picosiblings is r-degree keying
polynomial: K(y) =
r∑
j=0
kjyj
Encryption key
The encryption key for bin β is K(β)
Note: r = 0 corresponds to Pico’s original design, where every
credential is encrypted using a single key
9 of 21

10. Bivariate secret sharing
Bivariate polynomial
In order to share an entire keying polynomial K(y), rather than a single
encryption key, we now have the Pico create a bivariate polynomial
F(x,y) of degree (k − 1, r)—that is, of degree k − 1 in x and of degree
r in y:
F(x, y) =
k−1∑
i=0
r∑
j=0
aijxi yj
10 of 21

11. More details...
Let F be a finite field; V be a vector space over F; k, r, and n be
non-negative integers with 1 ≤ k ≤ n; and α1, . . . , αn be arbitrary
distinct non-zero elements of F.
1. For 0 ≤ j ≤ r, set a0j = kj, and for 1 ≤ i ≤ k − 1 and 0 ≤ j ≤ r,
select aij uniformly at random from V. Then construct the
bivariate polynomial F(x, y) ∈ V[x, y] as above.
2. For each 1 ≤ i ≤ n, compute the degree-r polynomial
fi (y) = F(αi , y) ∈ V[y], and send fi (y) (the share) to participant
i. (Note that the amount of storage this requires at each
participant is r + 1 elements of V.)
11 of 21

12. Enrollment
1. The Pico selects an arbitrary unused non-zero αi ∈ F to serve as
that Picosibling’s Picosibling identifier.
2. The Pico and Picosibling are paired establishing a shared
symmetric communication key CKi (P → PS : CKi ).
3. The Pico stores CKi in its tamper-proof memory.
4. The Pico creates the keying polynomial K(y) (as above), and uses
it to encrypt the credential database.
5. The Pico sends to the Picosibling the coefficients fi0, fi1 ∈ V of its
share of the keying polynomial (P → PS : {fi0, fi1}CKi ).
12 of 21

13. Query share/presence
For bin identifier β, we wish to reconstruct just the single value
K(β) ∈ V, and not the whole polynomial K(y). To accomplish this:
1. Send the value β to k Picosiblings (P → PS : {β}CKi )
2. Each Picosibling i will compute vβi = fi (β) = F(αi , β)—a single
value in V.
3. Each Picosibling i will reply with vβi (PS → P : {vβi }CKi ) V.
4. The Pico performs Lagrange interpolation on the (αi , vβi ) pairs in
the usual way to recover F(0, β) = K(β).
13 of 21

14. But why didn’t you just...
Ring 0 encryption (TRESOR)
Prototype Pico based on non-Intel CPU Pico, therefore don’t have
available registers (SSE, debug, AES-NI)
Cache-as-RAM (FrozenCache)
Negative impact on performance
Trusted Execution Environment (Secure enclave/Crypto processor)
Goal was low cost approach suitable for prototying
14 of 21

15. Requirements
1. Be small enough to be attached (unobtrusively) to a range of
items that users already frequently carry (such as wallets, phones
and keys).
2. Be able to be integrated into items that users carry or wear.
3. Operate for many months without charging or replacing batteries.
4. Be cheap to purchase and replace.
15 of 21

16. Bluetooth Low Energy
1. Low power
▶ Designed around button cell batteries
▶ Designed to exploit asymmetry
▶ Optimizations include: high-date rate, small packet sizes,
connectionless. . .
2. Small size and cost
3. Compatible with large installed base of mobile phones and tablets
Security (not so much)
BLE pairing broken (Ryan 2013)
16 of 21

17. COTS BLE platform
▶ High-performance low-power 8-bit
8051 processor
▶ 256 KB flash and 8 KB RAM
(retianed across all power states)
▶ Peripherals including watchdog, and
general purpose timers, 2x USART,
I2C and AES coprocessor
▶ 6mm x 6mm QFN40 package
17 of 21

18. Power mesurements
Results
1. ”Idle” (left)
2. Query (below)
18 of 21

19. Results
▶ Prototype gives 165-220 days use on CR2032 battery
▶ Introduces 2-3 second latency
▶ Optimizations may offer 50% longer battery life
19 of 21

20. Conclusions
▶ Original Pico design vulnerable to memory readout attacks
▶ Bivariate secret sharing can protect all long term credentials
expect the one currently being accessed
▶ Key storage costs (1); 256bits
▶ Prototype implementation predicted to operate for many montsh
with charging or replacing batteries
20 of 21

21. Questions?
21 of 21