Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

From Bitcoin Hardware Wallets to Personal Privacy Devices

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio

Eche un vistazo a continuación

1 de 36 Anuncio

Más Contenido Relacionado

Presentaciones para usted (18)

A los espectadores también les gustó (20)

Anuncio

Similares a From Bitcoin Hardware Wallets to Personal Privacy Devices (20)

Más de MecklerMedia (20)

Anuncio

Más reciente (20)

From Bitcoin Hardware Wallets to Personal Privacy Devices

  1. 1. From Bitcoin Hardware Wallets to Personal Security Devices Inside Bitcoins Seoul 2015
  2. 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. 3. Key protection Malware, (side channels, covert channels) Independant devices Static validation only Check destination, amount Hardware Wallets today
  4. 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. 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. 6. Arbitrary signature Mails, contracts, GnuPG, ... Arbitrary encryption (export warning …) Mails, messages, GnuPG, … Identity FIDO, SSH, ... Other generic use cases LEDGER
  7. 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. 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. 9. Dynamic applications Isolation of critical components Performance (size and speed) Technical issues LEDGER
  10. 10. Provisioning strategy Signed by the device / App Store Storage Internal or External General purpose APIs First software isolation layer Dynamic applications LEDGER
  11. 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. 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. 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. 14. User downloads a signed application Provisioning strategy (app store with common apps, no personalization) LEDGER
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Very simple architecture No risks Predictable performance No optimization Open Source licensing MIT Low level Virtual Machine : moxie LEDGER
  32. 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. 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. 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. 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. 36. Thank you Inside Bitcoins Seoul 2015

×