This document discusses how blockchain transactions can be made more secure through the use of device identity rooted in hardware. Keys are generated and stored in a trusted execution environment isolated from the main operating system. Key properties like being non-migratable or migratable can be enforced. Attestations about the device and keys can be recorded on the blockchain to prove the integrity and security of keys being used. This allows applications to achieve a higher level of trust for transactions by authenticating users through their devices rather than passwords.
3. Digital Assets Migrate
• Transition from cloud-based user assets to device-hosted assets
• Cryptographic keys provide direct interaction with the
blockchain
• Access to applications without “login”
• Username/password being enhanced with MFA
4. Example Digital Assets
• Cryptocurrency keys
• 2FA codes
• Financial account credentials
• Healthcare ID
• Identity / Government ID / License
• Affinity Programs
• eCommerce credentials
• Social media credentials
• Enterprise credentials
5. Blockchain Trust is Decentralized
• No central computer to trust
• No central entity to trust
• Trust is achieved by incentive rewards and consensus of the
participating nodes.
6. Blockchain Applications Achieve Trust
• From fintech to healthcare to supply chain management to
identity, blockchain services and business models benefit from
ledgers, immutable data, and decentralized security
• Users and devices participate in transactions on advanced
networks that are secured with cryptography, incentives, and
consensus algorithms
• Service providers desire to ensure correct user and device
permissioned for movement of digital assets and participation
in contracts
• Most business models require strong user and/or device identity
• Authorization
• Audit
7. Keys (Assets) have no Trust
• Who has the key?
• First thing an HDW wallet does is export key
• Many examples of wallet hacks involving private key
compromise
• Generally, we have no idea where our keys were created, where
they are, and where they have been
8. Device Identity is Weak
• Devices are commonly identified by MAC Address and IP
Address
• Easily modified
• Take a previously authorized device to a new blockchain network service
provider and why is it identified as a new device?
9. Trusted Computing Principles Solve
These Challenges
• Device Identity is Rooted in Hardware
• Isolated execution ensures that assets can be generated and
used without disclosure
• Sealed storage ensures that opaque key blobs can only be
accessed in these trusted execution environments
• Keys of different types are generated under this root of trust
• Non-migratable keys
• Migratable Keys
• Certified Migratable Keys
10. Trusted Execution Environment (GP)
• An execution environment that runs alongside, but isolated
from a Real Execution Environment (REE) of the Application
Processor.
• It has security capabilities and meets certain security-related
requirements
• Non-observable execution ensures operations cannot leak assets
• Sealed storage ensures assets are only available on a particular platform
• One or more Security Domains ensures assets can be fire-walled
• Certified set of security services ensure compliance to industry standards
• It protects TEE assets from general software attacks, defines
rigid safeguards as to data and functions that a program can
access, and resists a set of defined threats.
11. Strong Key Properties in Edge Devices
• Non-migratable keys
• Ensure that the digital asset is never allowed out of a trusted
environment.
• Any change to the device identity makes the key unusable
• Migratable Key
• May be migrated to any other device under control of the device owner
• Certified Migratable Key
• May be migrated to any other device under control of the device owner
• May be escrowed to an Escrow Authority under control of the device
owner
• Number of migrations and devices where asset has been migrated to is
tracked
• Controlled replication and destruction can be enforced
12. Root of Trust (RoT)
• A set of unconditionally trusted functions on a compute platform
• Must work properly each time executed, independent of any other
software that is executing on the platform
• Should be immune to (modest) physical attack
• May support the following security services:
• Authentication
• Confidentiality
• Identification
• Integrity
• Measurement
• Authorization
• Reporting
• Update
• Verification
13. Attesting to TEEs and Keys
1. Ability for unique instance of an immutable image (boot ROM) to
measure and verify the code it is about to launch
• Enhanced RoT services
• Boot Loader
• TEE
• Other critical security services
2. Ability for a RoT to assert provenance on a key
3. Includes information such as device identity, boot integrity, OS
versions, and other relevant platform security posture information
4. Access control policies
• User authentication
• Geolocation
• Time based
• Service Provider Whitelist/Blacklist
14. Example Transitive Trust
3. Execute
Extended
ROM
4.Execute
POST
&
BOOT
1.Execute
TEE
9. Execute
5. eRoT Verification
Crypto
Module(s)
8. Record
7. eRoT Verification
6. Record
eRoT Reporting
Root of Trust
2. Verification Checks
15. Security Domains
• Multi-tenancy allows Service Providers to co-exist without data
compromise
• Profiles within Security Domains allow key sets to exist in one
and only one context
• Personal, Enterprise
• Mom, Dad, Alice, Bob
• Owner, Service Personnel
rSD-1
TA-211 TA-212
TA-111
TA-112
Factory
Installed
SD-21
SD-11TA-11
16. Asserting Policy on Keys
1. Individual keys can have policy applied to them, and enforced
locally within the trusted execution environment
2. Policy can be simple or complex
• Did my platform change since the last time I used this key?
• Is the address I intend to transact with on a whitelist?
• Has an external oracle authorized my use of a specific service?
• Is my other device within Bluetooth range of this key?
• Can another one of my devices provide a second signature for a multi-key
operation?
• Has a user performed a biometric authentication to release the use of
this key?
17. Certified Key Containers and Operations
1. Cryptographic modules are specified by organizations such as
NIST and certified according to FIPS standards
2. Secure Elements are documented and certified by Common
Criteria Labs to meet protection profiles and corresponding
standards
3. Software products are documented and certified by Common
Criteria Labs to meet protection profiles and corresponding
standards
4. We must transition protection and use of digital assets to
certified containers, and ensure that users have the option to
choose safety and quality.
18. Auditable by Recording on the Ledger
With RoT, Trusted Execution, Key Types, and Security Domains, we
can record information on the blockchain within the transaction
• Strong Device Identity
• Integrity of Key
• Posture of Device
• Certifications on Key Containers
• Policies enforced locally
• Policies enforced remotely
• Remote policy entities
19. Applications Become Trusted with
Provable Keys
• Exchange Trading – authenticate device instead of
username/password/2FA
• Cryptocurrency Wallet – escrow key with central trust authority
(without disclosure) or decentralized contract to enable
recovery
• Cryptocurrency wallet – provably move key from one device to
another
• Trading Desk – enforce multi-sig transactions on specific
terminals
• Securities Trading – enforce KYC/AML
Known
User
Known
Device
Known
Condition
Assured
Instruction
20. The Rivetz Network
Provable Cybersecurity Controls
• Protection of Digital Assets with Policy Control
• Attestation and Recording of Device and Asset Quality as part of
Transaction
• Collections of User Devices Simplify and Safeguard the
Experience
Visit us at Booth #27
www.rivetz.com
t.me/Rivetz_Corp
@Rivetz
/r/Rivetz
@RivetzCorp