Presented by Nicolas Bacca

1. From Bitcoin Hardware Wallets
to Personal Security Devices
Inside Bitcoins Seoul 2015

2. Nicolas Bacca, CTO, Ledger
Secure Element solutions architect
Whitehat security reports
https://github.com/btchip/trezor-security-exploits
http://fr.slideshare.net/EricLarcheveque/bitcoin-
hardware-wallets-security
About me
LEDGER

3. Key protection
Malware, (side channels, covert channels)
Independant devices
Static validation only
Check destination, amount
Hardware Wallets today

4. Confirming a transaction is
complicated
Common use case : web purchase is
not covered
BIP 70 helps, but is not supported by Hardware
Wallets yet
BIP 70 is merchant centric
PKI issues again - how to validate certificates,
how to revoke certificates on a disconnected
User Experience limitations
LEDGER

5. Colored Coins with multiple kernels
Open Assets popular right now
Blockchain proofs
Augur, Bitproof ...
More Smart Contracts in the future
New protocol layers
Sidechains, Hubs
Growing, dynamic use cases
for Blockchain applications
LEDGER

6. Arbitrary signature
Mails, contracts, GnuPG, ...
Arbitrary encryption (export warning …)
Mails, messages, GnuPG, …
Identity
FIDO, SSH, ...
Other generic use cases
LEDGER

7. User Experience should be
customizable
One size doesn’t fit all
Valuable assets go way beyond the
transaction amount.
Moving targets for
Blockchain applications
LEDGER

8. More complicated to revoke
Can not just send the coins to another address
Open plug-ins complexity
Additional leak risks if not properly isolated
Growing security concerns
LEDGER

9. Dynamic applications
Isolation of critical components
Performance (size and speed)
Technical issues
LEDGER

10. Provisioning strategy
Signed by the device / App Store
Storage
Internal or External
General purpose APIs
First software isolation layer
Dynamic applications
LEDGER

11. User enrolls the device locally
User signs the generic application
Optionally recompiles / checks it
User installs the signed application
Now specifically trusted for this device
Provisioning strategy (self)
LEDGER

12. User enrolls the device into App Store
App Store encrypts the application
App Store personalizes the application
Can be device specific, encrypted
Provisioning strategy (app store
with secret in apps)
LEDGER

13. User enrolls the device into App Store
App Store signs the application
App Store personalizes the application
Can be device specific, encrypted
Provisioning strategy (app store
with common apps, enrollment)
LEDGER

14. User downloads a signed application
Provisioning strategy (app store
with common apps, no
personalization)
LEDGER

15. Different models
Easier if no secrets in apps, no personalization
Can be mixed
App Store and specific user trusted applications
Provisioning strategy
LEDGER

16. Requires a fine flash management API
Sectors are too big for some MCUs
Filesystem issues
Reorganizations, wear leveling and anti tearing
Helps for a standalone device
Also for collaboration between applications
Internal storage
LEDGER

17. Requires “large” available RAM space
Or a mixed storage strategy, not efficient
Not standalone
Need to always have the application around
Replay issues if everything is external
On board application state storage is easier
External storage
LEDGER

18. Internal Storage easier when possible
Pick the right MCU or use Secure Elements
Otherwise compromises to be made
Application state storage & overall usability
Storage
LEDGER

19. Isolation of the cryptographic materials
Most important thing to do whatever the use
Different use cases
Wallet plugin or full application oriented
General Purpose APIs
LEDGER

20. Signature APIs to be validated
Might control but not sign blindly
Handle new outputs, TX formats
For example Payment Protocol or colors
Provide additional TX information
On screen display or confirmation logic
Wallet plugin APIs
LEDGER

21. API provide basic building blocks
Crypto, I/O
Everything else implemented using it
Full wallet and extensions
Isolation is critical
Typically prevent raw flash reads
Full application oriented API
LEDGER

22. Way more complex than full isolation
Isolation, with some firewalling logic
Specific implementation can help
Virtual machine easier than bare metal
Also concurrent execution to consider
Way easier if not supporting it
Inter application communication
LEDGER

23. Architecture to be chosen
“Full” is more flexible, if doable on the platform
Isolation is the most critical asset
Proper crypto APIs is the second one
Key protection, side channel resistant
General Purpose APIs
LEDGER

24. High level virtual machine
Used in high level languages
Low level virtual machine
CPU emulation, target standard C code
Hardware assisted
Can also help in VM development
Isolation strategies
LEDGER

25. How easy is it to audit
Carefully audit optimizations (native translation)
Sandbox escaping : type confusion
Raw pointer access risk, invalid bytecode
Sandbox escaping : native interface
Audit argument checks
Security of a High level virtual
machine
LEDGER

26. Well audited security model
Earliest Virtual Machine around
Flexible performance
Different versions, see also Java Card
Complicated licensing
Free/OSS embedded implementations at risk
High level Virtual Machine : Java
LEDGER

27. Simple security model
Easy to audit (bytecode similar to Java)
Predictable performance
No optimization in the default version
Licensing to be validated
Apache, but some IP claims in the past
High level Virtual Machine : Dalvik
LEDGER

28. Security model to be validated
Different complex types, lists
Flexible performance
No optimization or machine translation
Open Source licensing
MIT
High level Virtual Machine :
microPython
LEDGER

29. Security model to be validated
Different complex types
Predictable performance
No optimization
Open Source licensing
MIT
High level Virtual Machine :
embedded Lua
LEDGER

30. How easy is it to audit
Carefully audit optimizations (native translation)
Sandbox escaping : native interface
Audit argument checks
Security of a Low level virtual
machine
LEDGER

31. Very simple architecture
No risks
Predictable performance
No optimization
Open Source licensing
MIT
Low level Virtual Machine : moxie
LEDGER

32. Memory Protection Unit
Isolate memory areas (flash / RAM)
Supervisor mode
Lock the MPU
MPU + SU enable “trap” service calls
Isolate the core APIs and the applications
Hardware assisted isolation
LEDGER

33. Optional for ARM M3 MCUs
Found in some MCU, not entry level
Common for ARM Secure Elements
SC000 / SC300
Hardware assisted isolation support
LEDGER

34. Native isolation when supported
C code with native performance
Moxie VM when not supported
Source code portability
Optional lightweight Dalvik on top
For Java (Card) developers
Ledger implementation
LEDGER

35. Java Card playground for the high level API
https://github.com/ledgerhq/ledger-javacard (soon)
Trusted Execution Environment public beta,
high level isolation prototype
Open Source isolation product coming up Jan
2016 for developers (Ledger Blue : USB, BLE,
NFC, screen)
Follow up with Ledger
LEDGER
@LedgerHQ

36. Thank you
Inside Bitcoins Seoul 2015