This document summarizes Scott G. Kelly's presentation on secure boot flaws in IoT and embedded systems. Kelly discusses how secure boot is intended to work by only allowing authorized firmware to run, but that many systems implement it incorrectly. Common flaws include using symmetric keys that can be extracted from devices, having an "optional" secure boot that can be easily disabled, and having a weak root of trust if the first code executed is stored in unprotected flash. Kelly urges vendors to properly implement secure boot to prevent malware from replacing firmware and compromising systems.

1. Secure Boot
They’re doing it wrong.
Scott G. Kelly
March 15, 2017
CanSecWest 2017

2. Who am I?
• Platform security architect, Netflix
– Consult with System on Chip (SoC) and embedded device
designers/manufacturers on security design and
implementation
– Design reviews of hardware/firmware
– Code reviews for security-critical elements
– Make recommendations
• Mitigation strategies for current issues
• Design changes for future products
• Development process changes
March 15, 2017 CSW 2017 2

3. Why am I here today?
• Connected systems are proliferating
– Smart {phone,TV,STB,alarm,<fill-in>}
• Everything connected to the Internet will be
probed by predators
– And in some cases, pwned.
• It’s early, but the cracks in IoT/embedded are
already serious.
March 15, 2017 CSW 2017 3

4. March 15, 2017 CSW 2017 4
https://arstechnica.com/staff/2017/02/router-assimilated-into-the-borg-sends-3tb-in-24-hours/

5. March 15, 2017 CSW 2017 5
https://www.wired.com/2016/12/botnet-broke-internet-isnt-going-away/

6. What devices did mirai subvert?
March 15, 2017 CSW 2017 6
https://krebsonsecurity.com/tag/mirai-botnet/

7. March 15, 2017 CSW 2017 7
http://www.zdnet.com/article/ransomware-now-locks-your-smart-tv-and-then-demand-apple-itunes-gifts/

8. You get the picture.
• The list is surprisingly long already.
• The (simple!) problem is that these products allow indiscriminate
firmware modification/replacement
– Geeks might like this
– So do predators.
• Ultimately, the pwned system is not behaving according to
expectations. Whose expectations?
– Manufacturer
– Service provider
– Owner/User
– Internet community
March 15, 2017 CSW 2017 8

9. Malware in IoT/Embedded Systems
• How does it happen?
– Sometimes, device makers are
STUPID^H^H^H^H^H^Hnaive, and ship with Internet-
accessible telnet/web access with default password
– But usually, it’s a consequence of system complexity
• Everyone wants more features
• More features == more software
• More software == more bugs
• Some of those bugs will be security-relevant
March 15, 2017 CSW 2017 9

10. IoT systems are hard to secure
• Why?
– Many bugs and vulnerabilities
• Function of complexity, skill
of contributors, engineering
decisions, etc.
– Network-accessible interfaces
– Providers lack incentives for
maintenance, security
patches
• Devices are cheap
• No consequence for breach
• Fire and forget
March 15, 2017 CSW 2017 10
X = critical bug

11. But… Linux is secure – isn’t it?
March 15, 2017 CSW 2017 11
http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

12. Linux is complex
• Linux is an awesome OS
• Annual vulnerability count is a function of the
innovation level
• But software has bugs. The more software,
the more bugs. And some bugs lead to sploitz.
March 15, 2017 CSW 2017 12

13. Internet Explorer
March 15, 2017
Source: http://www.cvedetails.com/product/9900/Microsoft-Internet-Explorer.html?vendor_id=26
CSW 2017 13

14. Chrome
March 15, 2017
Source: http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224
CSW 2017 14

15. Firefox
March 15, 2017
Source: http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452
CSW 2017 15

16. Safari
March 15, 2017 CSW 2017 16
http://www.cvedetails.com/product/2935/?q=safari

17. Complex software is difficult to secure
• It will always be difficult to secure rich
applications
– Major browser vendors are all very competent
– Yet, they regularly push security patches
– We have to accept that sometimes, sploitz will happen.*
• But, we don’t have to allow malware to replace
trusted code (e.g. bootloaders, OS, system
software, etc.)
– Not if we correctly implement secure boot.
March 15, 2017 CSW 2017 17

18. So, what is Secure Boot?
• Put simply, means that only authorized system code runs
– If image is corrupted, or you try to install your own (unauthorized)
code, system will not run.
• Cool! Why don’t they have that for Windows?
– Actually, they do, sort of (it’s called UEFI).
– See Vincent Zimmer’s excellent CSW-15 presentation
(https://cansecwest.com/csw15archive.html)
• Today, we’ll focus on embedded/IoT
• So, how is secure boot implemented? We need some
background first.
March 15, 2017 CSW 2017 18

19. Embedded Systems 101
• Embedded systems
generally include
– NAND/NOR Flash
• non-volatile memory in
which firmware is stored
– CPU
• processor for OS/apps
– DRAM
• random access memory
(just like your PC)
– Interfaces
• Wifi, ethernet, etc.
March 15, 2017 CSW 2017 19

20. Embedded Systems 101 (2)
• At power-on
– Processor comes out of reset
– Begins running code from ROM
or flash*
• Boot Loader (BL) is first non-
ROM firmware to run
• ROM/BL initializes HW
(memory, etc.)*
• BL copied (by ROM or self)
into DRAM before continuing
March 15, 2017 CSW 2017 20

21. Embedded Systems 101 (3)
• BL continues hardware
initialization from
DRAM
• BL validates, loads, and
jumps into OS kernel
• OS finishes init, goes to
runtime steady state
March 15, 2017 CSW 2017 21

22. Important Observations
• IoT devices often have multiple processors/cores
– Application processor (may be SMP) is but one
– Audio/video, networking, GPU, all use processors
– Various others (depending on device type, applications)
• These cores run distinct instruction streams (software)
– They are often not controlled by application CPU OS
– What resources they share (e.g. memory, buses, etc.) are design
choices
• Frequently, they are DMA masters
– Meaning they have full run of DRAM
– Read and write.
March 15, 2017 CSW 2017 22

23. Sample IoT Architecture
March 15, 2017 CSW 2017 23
http://www.arm.com/images/processor/Mobile_Computing_Diagram_550.jpg
Processor
Processor
Processor
Processor
ProcessorMain Processor Processors

24. Back to the future
• Attackers are exploiting IoT systems by
modifying/replacing malleable firmware elements
• Need a way to prevent this, while still allowing
authorized updates/app loading
• Enter secure boot?
– We need system to be extensible, flexible
– This means we can’t necessarily protect everything.
– How to solve this?
March 15, 2017 CSW 2017 24

25. Simplistic view of secure boot
• On reset, processor starts
from ROM
– (Practically) immutable code
• ROM code loads/verifies
bootloader
– If invalid, halt.
• Bootloader loads/verifies OS
and r/o filesystem(s)
– If invalid, halt.
• Only verified (authorized)
firmware is allowed to run.
ROM
Bootloader
OS (e.g. Linux)
Filesystems
Public key
Signature
Signature
Signature
Verifies
Verifies
March 15, 2017 CSW 2017 25

26. What else happens during boot?
• All system security essentials
are configured
– Memory protections are established
– Privileges granted where needed
– Basic enforcement framework is
instantiated (hardware and software)
and locked down
• Helpful to think in terms of
ratchet locks
– Can go forward, but going back
requires complete reset
March 15, 2017 CSW 2017 26

27. Post-boot Secure Execution Environment
• Secure environment
established
• Everything inside of
boundary is in known
state
• Can “trust” this system
– It will behave in a
predicable way, as
expected*
CSW 2017March 15, 2017 27

28. Subverting the boot process
• Malware often circumvents boot process
– Attack replaces some part of early boot code
– Takes control of the system early on
– Robust secure boot can prevent this.
• Of course, application may exploit system bug (later)
– But robustly configured system can still protect some
assets, operations
– This is the purpose of hardware-based “ratchets”
• Compromise at later phase can’t undo previous “locks”
– System can potentially be recovered by reboot
CSW 2017March 15, 2017 28

29. How to Attack Secure Boot?
• Glitching
– Cause system to erroneously accept (or ignore!) invalid signature
• Compromise signing key
– Then, you can sign your own firmware images!
• Break crypto (e.g. factor RSA modulus)
– Yeah, good luck with that.*
• Find bug/flaw in validation code
– Buffer overflow, integer {under,over}flow, etc.
– Incorrect crypto implementation
• Take advantage of flawed design.
CSW 2017March 15, 2017 29

30. Secure Boot Flaws in the Wild
• Most IoT systems don’t implement secure boot
– This must be remedied.
– Maybe someone will sue some of these
manufacturers?
– Or, maybe it will require regulation.
• However
– Many systems that seem to have secure boot actually
do not.
– They’re doing it wrong.
March 15, 2017 CSW 2017 30

31. Flaw 1: symmetric key
• Two ways in which symmetric keys are used:
– Encrypt the firmware*
– Compute keyed MAC (e.g. HMAC-SHA256) over firmware
• Encryption is not authentication/integrity verification!
– Encrypted files can be changed in targeted ways
• The (shared!) key is on the device.
– Root the device, extract key.**
– Generate “valid” firmware.
– Distribute firmware to other related devices.
– Refuse manufacturer/user updates.
– D’oh!
March 15, 2017 CSW 2017 31

32. Flaw 2: ”optional” secure boot
• Vendors like to be able to turn secure boot off for
development
– So engineers can build/flash/test without signing
• How this policy is implemented/enforced is critical
– Normally, by blowing e-fuse/OTP bits
– Once done (in factory), cannot be undone
• But, this vendor reads the policy from unprotected flash:
– http://www.fredericb.info/2016/10/amlogic-s905-soc-
bypassing-not-so.html
– Don’t want secure boot? Hex edit one 32-bit value and it is off!
– D’oh!
March 15, 2017 CSW 2017 32

33. Flaw 3: Weak root of trust
• Secure boot depends on root of trust
– Normally, starts from ROM
– If first code that runs can be changed, you are potentially in the
matrix
• PCs still have this issue (start from BIOS/EFI flash). Due to
scalability/liability issues?
– Trammell Hudson illustrated the issue with thunderstrike:
• https://trmm.net/Thunderstrike_31c3
• Macbook, some PCs implement UEFI
– But so long as EFI flash can be rewritten, this is fundamentally
flawed
March 15, 2017 CSW 2017 33

34. Flaw 3: weak root of trust (2)
• This same problem exists in many IoT devices
– To save on cost, sometimes no ROM
• Processor loads first stage bootloader from unprotected flash
• What if attacker re-flashes?
– There are hardware-based methods for protecting the flash at
runtime
• Update window is opened early in boot process
• If valid, signed image is found, update occurs
• One-shot lock requires reboot to “open the window” again
• But these cost money, so not often implemented.
– Regardless, still cannot prevent physical attack
• e.g. using teensy: https://trmm.net/SPI
March 15, 2017 CSW 2017 34

35. Flaw 3: weak root of trust (3)
March 15, 2017 CSW 2017 35

36. Flaw 4: RSA with no padding
• This is a surprisingly common problem
• Some engineers eliminate RSA padding to save
space
– Has no impact on signature size
– Slightly reduces code size/complexity (in ROM)
• Creates subtle issues
March 15, 2017 CSW 2017 36

37. RSA “padding” is critical to security
Standard (PKCSv1_5)
padding
• “Armoring” is a better term
• Astronomically narrows degrees of
freedom for attacker
• Limits ability to generate new
signatures based on algebraic
manipulation of collected signatures
• Prevents some attacks on small
exponents
March 15, 2017 CSW 2017 37

38. RSA Signing/Verification Overview
RSA decrypt +
padding verify
RSA Pad + Encrypt
Raw firmware
Signed firmware
March 15, 2017 CSW 2017 38

39. Flaw 5: “clever” crypto
• Security is hard. Cryptography is harder.
– Almost always the case that engineers implementing
the crypto do not understand it.
– There be dragons.
• I’ve seen many cases of crypto modifications,
shortcuts, “optimizations":
– To save space
– To speed boot process
– Because it’s just math*
March 15, 2017 CSW 2017 39

40. Hacking Secure Boot
A worked example
• “It’s just math”
• Above, we saw that a robust secure boot process uses
asymmetric cryptography to implement a digital
signature algorithm
– RSA, ECDSA, etc.
• Following is an example of how wannabe clever
engineers gave me the keys to their kingdom.
– Some details have been changed to protect vendor
confidentiality
– But the essence of the flaw remains.
March 15, 2017 CSW 2017 40

41. 20K’ View of idealized early boot process
• SoC comes out of reset, execs
code from ROM
• ROM code inits h/w, loads
Kpub into DRAM, verifies it,
and then uses it to verify
Loader0
• If verification fails, system
refuses to boot
• Attacker objective: replace
Kpub (and Loader0, etc.)
CSW 2017
Loader0
Loader1
TEE code
Uboot
Linux
Filesystem
NAND
CTRL
DRAM
CTRL
ROM
CPU
SoC
DRAM
NAND
Kpub
Kpub
Loader0
March 15, 2017 41

42. Why should breaking this be hard?
• Because breaking RSA is hard.
• Only way to replace Kpub is by
forging signature.
• Forging signature means
compromising signing
key/process
• But they did not sign Kpub
– Wait. What???
CSW 2017March 15, 2017 42
Loader0
Loader1
TEE code
Uboot
Linux
Filesystem
NAND
CTRL
DRAM
CTRL
ROM
CPU
SoC
DRAM
NAND
Kpub
Kpub
Loader0

43. RSA in brief (1)
• RSA depends on modular division
• “Normal” integer division:
– 6 / 4 = 1 (remainder 2)
• Modular division:
– 6 mod 4 ≡ 2 (where ≡ means ”is congruent to”)
– Alternatively: 6 ≡ 2 (mod 4)
• Think about time of day:
– What time will it be 24 hours from now? 36 hours from now? 48 hours
from now? (n * 24) + 1 hours from now?
– That’s modular division (modulus is 24 or 12, depending on style)
March 15, 2017 CSW 2017 43

44. RSA in brief (2)
• RSA essentials:
– There is a modulus (n), a very large number
• For this example: |n| = 2048 bits (22048 = 3.2 * 10616)
– There is a private key (d)
– There is a public key (e)
– There is a message (M) that you want to either encrypt or sign
• Deceptively simple:
– RSA encryption:
• C = Me mod n
– RSA decryption:
• M = Cd mod n
Ciphertext
Plaintext
March 15, 2017 CSW 2017 44

45. RSA in brief (3)
• Really?
– C = Me mod n, M = Cd mod n
– That’s it?
– Well, sort of*
• Notice:
• M = (Me mod n)d mod n
– Because of modular algebraic properties:
• M = (Me mod n)d mod n = Med mod n
• d and e are related: they are multiplicative inverses mod <x>**
• So, n, d, and e are special. If not chosen carefully, RSA doesn’t work as
expected.***
March 15, 2017 CSW 2017 45

46. One critical bit of RSA advice
• Never EVER encrypt raw messages (M) with RSA
– i.e. C = Me mod n ? Don’t do it.
– Depending on what you encrypt, and details of your specific
keys/modulus, various attacks are possible
– This is *really* important!
• I’ll show you exactly why shortly.
• See Dan Boneh’s paper for more info:
– https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf
March 15, 2017 CSW 2017 46

47. “Normal” firmware packaging approach
CSW 2017
This is (more or less) what a secure boot image
typically looks like
Simple: signature is appended, stored with firmware
Firmware element0 Digital signature0
Firmware element1 Digital signature1
Firmware element2 Digital signature2
Firmware elementn Digital signaturen
:
:
March 15, 2017 47

48. “Clever” firmware packaging
Kpriv: OEM RSA private (firmware) key
Kpub: OEM RSA public (firmware) key
Loader0: first stage bootloader
Vpriv: Vendor RSA private key (vendor keeps this
secret)
Vpub: Vendor RSA public key (in ROM)
H0: hash of Loader0
H1: hash of Kpub
RSAe(blob1): vector of H0,H1, additional 512
bits, padded/encrypted with Kpriv
RSAe(Kpub): modulus of Kpub, encrypted with
Vpriv
Kexp: (public) exponent for Kpub
March 15, 2017 CSW 2017 48
Loader0
RSAe(blob1)
RSAe(Kpub)
SHA256
Kpub
H1
(other stuff)
H0
Kpriv
Vpriv
SHA256
RSAe
RSAe
ROM
Vpub
Kexp
blob1
flash

49. 20K’ View of “clever” boot process
• SoC comes out of reset, execs code
from ROM
• ROM code inits h/w, loads
RSAe(Kpub): into DRAM, decrypts
with Vpub
• Loads RSAe(blob1), uses Kpub to
decrypt
• Extracts H1 from blob1, compares
hash of Kpub
– If not matched, reset
• Extracts H0 from blob1, hashes
Loader0 and compares
– If not matched, reset
CSW 2017March 15, 2017 49
Loader0
RSAe(blob1)
RSAe(Kpub)
SHA256
Kpub
H1
(other stuff)
H0
Kpriv
Vpriv
SHA256
RSAe
RSAe
ROM
Vpub
blob1
flash
Kexp

50. It just feels wrong
• Why aren’t they using signatures?
– “encrypting” instead, and with private key
• No padding on RSAe(Kpub)
– Numerous papers describe related attacks
• Decrypted Kpub is used before it is verified
March 15, 2017 CSW 2017 50

51. First crack in the armor
• What if we set RSAe(Kpub) to 1?
• RSAd(RSAe(Kpub)) = 1exp mod n = 1!
– We can force Kpub to 1
• if Kpub = 1
– RSAd(RSAe(blob1)) = (RSAe(blob1)3) mod 1 = 0
– This means the decrypted blob2 will be all
zeroes
• i.e. hashes will be all zeroes
– but SHA256(Kpub = 1) != 0, so secure boot will
halt here.
• Okay, setting it 1 doesn’t help us.
March 15, 2017 CSW 2017 51
Loader0
RSAe(blob1)
RSAe(Kpub) 1

52. First crack in the armor (2)
• What if we set RSAe(Kpub) to 0?
• RSAd(RSAe(Kpub)) = 0exp mod n
– We can force Kpub to 0
• if Kpub = 0
– RSAd(RSAe(blob1)) = (RSAe(blob1)3) mod 0
– mod 0 is “divide by 0”
– since this is ROM code (minimized), this could
lead to exploitable exception condition
March 15, 2017 CSW 2017 52
Loader0
RSAe(blob1)
RSAe(Kpub) 0

53. Any other options?
• 0/1 replacement attack seems impractical
– Is that all we’ve got?
• No:
– ROM code will decrypt any RSAe(Kpub) and use it
– This is a decryption oracle
• But what to do with this?
– We need to understand more about how/why RSA
works…
CSW 2017March 15, 2017 53

54. Why does RSA work?
• Fermat’s Little Theorem*
– Let p be a prime number. Then ap−1 ≡ 1 mod p for every integer a not
divisible by p
• Euler’s totient function φ(n)
– φ(n) counts the numbers in 1 < k < n where gcd(k,n) = 1 (coprime)
– Euler discovered |φ(n)| is the number of values in 1 < k < n that have a
multiplicative inverse mod n **
• Euler’s Theorem (aka Euler-Fermat Generalization)
– Yeah, yeah, Fermat was right, But, since p is prime, and since φ(p) = p -
1, Fermat really meant to say aφ(n) ≡ 1 mod n whenever gcd(a,n) = 1.
– In other words, modulus need not be prime as long as message (a) is
relatively prime to n
March 15, 2017 CSW 2017 54

55. Why does RSA work (2)?
• What’s a multiplicative inverse (MI)?
– x-1 is a number which when multiplied by x yields the multiplicative
identity, 1.
– i.e., x * x-1 = 1
– If we are computing mod n, x * x-1 = 1 mod n
• Recall: φ(n) counts the numbers in 1 < k < n where gcd(k,n) = 1
• Suppose we choose a modulus, n, and d: gcd(d, φ(n)) = 1
– Then, d*d-1 = 1 mod φ(n)
• How to find d-1 ? Use extended euclidean algorithm.
CSW 2017March 15, 2017 55

56. How does RSA work?
• Randomly choose 2 distinct (large) primes p and q
• Compute n = pq
– This is the RSA modulus
• Compute φ(n) = φ(p)φ(q) = (p − 1)(q − 1)
• We’ll use φ(n) to find multiplicative inverse pairs
– Security of RSA depends on difficulty of calculating φ(n) given n
– Doing so requires factoring n (need prime factors to compute φ)
– Since n is product of 2 large (>= 1024 bit) primes, this is hard.
March 15, 2017 CSW 2017 56

57. How does RSA work? (2)
• So, we have n = pq and φ(n)
• Now, choose (invertible) public exponent
– Choose an integer e : 1 < e < φ(n) and gcd(e, φ(n)) = 1
• Find inverse of e (mod φ(n))
– Compute d ≡ e−1 (mod φ(n)) using extended Euclidean
alg.
• e is the public key, d is the private key
• Now, C = Me mod n and M = Cd mod n*
March 15, 2017 CSW 2017 57

58. The oracle attack
• Recall: we have a RSA
decryption oracle here
• Put any number of random
values in for RSAe(Kpub)
• Decrypt with Vpub
• Do something*
March 15, 2017 CSW 2017 58
Loader0
RSAe(blob1)
RSAe(Kpub)
random

59. Do what, exactly?
• Think about what we learned about RSA
– If we can factor it, we can compute φ(n)
– With φ(n), since we know e==3, we can compute d*
• Recall: RSA security depends on the fact that n is
difficult to factor
– We purposely choose large p and q for exactly this reason
• But this is not n=pq; it’s a random value!
– What if our random modulus is easy to factor?
– Uhhh... when are 2048-bit numbers *ever* easy to factor?
March 15, 2017 CSW 2017 59

60. Decryption Oracle (2)
• Some 2048-bit numbers are easier to factor than others
– What if 2048-bit number is composed of all smaller factors?
• B-smooth:
– A number is B-smooth if none of its prime factors are greater than B
• Factoring as a service
– A group of U-Penn researchers led by Nadia Heninger built an AWS-based
service that factors 512-bit RSA moduli in ~4 hours for ~$75
• Putting this together
– Emailed Nadia asking if intuition is correct: we can factor 2256-smooth 2048-bit
moduli in comparable time using their service
– Odds of picking one of these at random is ~2-24 (1 in 16.7M)
– Rough calculations: ~4000 hours of compute time, $75000
March 15, 2017 CSW 2017 60

61. Can we do better?
• 4000hrs + $75K is definitely a barrier
• Nadia pointed out that some values would have 1 larger
prime factor
– Cost of finding these would be similar to 2256-smooth
– Just need a little more time to find last factor (or two)
• This encouraged me to keep poking at this
• A coworker suggested: how about modulus with only two
factors, large prime and 1?
– i.e. what if n is prime?
CSW 2017March 15, 2017 61

62. Decryption Oracle (3)
• Observations
– If random decrypted value (modulus) is prime, φ(n) = n-1
(remember Euler?)
– If gcd(e, φ(n)) = 1, can directly compute d (because we know e,
which is 3)
– With d, we can generate “valid” encrypted blob
• We can sign our own firmware. Total compromise!
– p(prime chosen at random) is 0.0007
– On 2015 macbook, takes average of 30 secs to find 2048-bit
prime and associated d (d is for d’oh!!!)
March 15, 2017 CSW 2017 62

63. The Exploit
• TRYAGAIN:
– Choose random value ri
– “decrypt” ri using Vpub
– Compute d for 3, D(ri)
– Sign/verify something with d,3
– If it fails, goto TRYAGAIN
• Use d to sign your firmware
• Write firmware, ri to flash
• Reboot!
• Important: ri and signed firmware can be
written to flash via software exploit.
– Point and click distribution is possible.
– Unrecoverable botnet, anyone?
March 15, 2017 CSW 2017 63
Loader0
RSAe(blob1)
RSAe(Kpub)
random

64. Wrap up
• IoT devices are cannon fodder due to lack of
secure boot
• Security is hard. Cryptography is harder.
– Do it by the book! Don’t try to be clever!
• We really need a solution for the IoT
insecurity problem. Think about it.
March 15, 2017 CSW 2017 64

65. Acknowledgements
• Nadia Heninger
– Her research pointed me in the right direction,
and her suggestions nudged me toward the
solution
• Filip Paun
– His RSA knowledge and insight were instrumental
in taking the exploit from 4hrs/$75K to < 30 secs
March 15, 2017 CSW 2017 65

66. backup
March 15, 2017 CSW 2017 66

67. Seen on crypto final somewhere
Recall that the RSA trapdoor permutation is defined in the
group ℤ∗N where N is a product of two large primes. The
public key is (N,e) and the private key is (N,d) where d is the
inverse of e in ℤ∗φ(N).
Suppose RSA was defined modulo a prime p instead of an
RSA composite N. Show that in that case anyone can compute
the private key (N,d) from the public key (N,e) by computing:
1. d←e−1 (mod p−1).
2. d←e−1 (mod p+1).
3. d←−e (mod p).
4. d←e−1 (mod p2).
March 15, 2017 CSW 2017 67

68. 20,000’ view
• Primary device security objective
– Establish/maintain secure execution environment
– Does what it is allowed to do
• e.g., be a thermostat, be a phone, be a camera, whatever.
– Doesn’t do what it is not allowed it to do
• e.g., steal your bank login, DDoS your favorite service provider, etc.
– It’s about maintaining control/containment, even if
applications behave inappropriately, unexpectedly
• Creation of secure execution environment requires
combination of software and hardware mechanisms
CSW 2017March 15, 2017 68

69. Examples of Execution Environments
• Java execution environment
– Provides limited operations, capabilities for applets
– Security “sandbox”
• Processor (e.g. Intel) execution environment
– “Set of resources for executing instructions and
storing code, data, and state information”
– e.g., ALU, registers, caches, privilege modes, mmu,
memory, storage, etc.
• Process execution environment (e.g. Linux/BSD)
– Virtual memory, reduced processor privilege level, etc.
CSW 2017March 15, 2017 69

70. Secure Boot prevents persistent hijack
• Goal of secure boot is to prevent modification
of system security foundation/framework
• For this to be effective, it must be robust
against attack*
• Not all “secure boot” mechanisms are created
equal
March 15, 2017 CSW 2017 70

71. Ideally, how is firmware/software verified?
• Each element is digitally signed
when created
– Usually with RSA*
• Verification requires a public
key that can’t be modified
– In ROM, OTP*, e-fuse
• Each link in the chain can use a
different key if desired
ROM
Bootloader
OS (e.g. Linux)
Filesystems
Public key
Signature
Signature
Signature
Verifies
Verifies
March 15, 2017 CSW 2017 71

72. Signature
Using multiple keys (a chain)
• Chip makers often program
their own public key into
ROM/OTP
– But don’t want to give private
key to each OEM
• Problem
– How can OEMs sign their own
firmware?
• Solution
– Chip vendor signs OEM’s public
key, this is used for firmware
verification
ROM
Bootloader
OS (e.g. Linux)
Filesystems
Vendor Public key
Signature
Signature
Signature
Verified with vendor key
OEM Public key
Verified with
OEM Public key
March 15, 2017 CSW 2017 72

73. Small exponent (3), no padding
March 15, 2017 CSW 2017 73
There are fewer perfect cubes than
intuition might suggest, but reduces
attacker work factor significantly
Forged Signature
SHA256 Hash
(H)
H1/3
|<—256 bits—>|
Empty!
modulus has no effect.
H
1/3
|<- 85 bits ->|

74. Secure Initialization is Essential
• Assuming all essential security hardware building blocks are
present, everything else depends on secure system
initialization
– System must boot into secure state
– Implies boot process is secured from power-on
• Secure boot design/implementation is one of the things I
consult on
– Sometimes I find issues.
– Usually, they can be fixed. Sometimes, they cannot.
• That’s what this talk is about.
CSW 2017March 15, 2017 74

75. Actual symmetric key hacks
• Asus SBK
– Asus EEE Transformer Tablet used symmetric AES key to validate bootloader,
image (SBK)
– Key is well protected within system, but it was leaked by insider (they since
changed SBK)
– http://www.overclock.net/t/1037242/twitter-asus-transformer-secure-boot-
key
– But they continued to use symmetric key.
• Samsung CMAC key
– Various Samsung DTV/BDP devices use symmetric key to validate bootloader,
Linux image, root filesystem
– Key is not well protected within system
– Attackers root device, directly read key.
– https://forum.samygo.tv/search.php?keywords=cmac&sid=089fdff1a665f34db
5fcf143f213c3c7
March 15, 2017 CSW 2017 75