Stronghold Enhancement Proposal: Hardware Secure Module Integration

[felsweg-iota]

Stronghold Enhancement Proposal: Hardware Secure Module Integration

Outline

Stronghold shall be extended to support secure hardware tokens as an alternative to purely software based memory protection. The integration shall be hardware agnostic, so virtually any hardware token can be used or the support for it can be easily shipped.

Motivation

Software based security only adds an additional layer of difficulty to attacks. If a system is compromised and a malicious actor gains privileged access, software based safeguards are not enough to protect valuable assets. Stronghold brings in a great deal of protecting memory, but relies on the stability of kernel based features.

Present day CPUs are partially equipped with hardware enclaves (like Intel TXT or ARM TrustZone) as well as hardware tokens as USB sticks are available from selected vendors. This gives Stronghold the opportunity to integrate support hardware secure modules (HSM).

The goal of this proposal shall describe how HSM can be integrated to store sensitive information, but still offering the flexibility to use software based memory enclaves.

Reference-Level Explanation

Architectural Overview

Integration

The proposed architecture distinguishes between hardware secure token support abstracted by the secure memory back-end, while providing the same functionality with software based solutions like the boxed types ( protected by libsodium ) as well as the non-contiguous types.

The HSM interface introduces one more level of abstraction by exposing common APIs to interact with HSM like PKCS#11 and API Libraries like PARSEC.

Accessing hardware secure modules is not directly exposed to the user, but can be configured in the upper layers of the Stronghold API.

Interface Definition

The interface is being split into low-level support for HSMs in general, and a more high level abstraction in how to integrate HSMs.

---

The most basic functionality of a HSM can be reflected by the following trait.

/// HSM is an abstraction over Hardware Secure Modules and 
/// are to be used as a handle. 
struct HSM {...}

/// The HSMContext is a stateful abstraction over a specific HSM
struct HSMContext {
 	handle : usize,  
}

/// HSMState is an indicator of the internal HSM state
enum HsmState {
	
	/// The user is being authenticated against the HSM
	Authenticated,
		
	/// The currently used HSM is in a Locked state
	Locked,
	
	/// The currently used HSM is unlocked
	Unlocked,
	
	/// A reference to an underlying [`HSMError`] while using the HSM
	Error(HSMError),
}

/// An error type to indicate all different failures interacting with
/// an HSM.
enum HSMError {
	
	AccessViolation(String),
}

/// An abstraction over a Personal Idenitication Number to unlock
/// a HSM
struct HSMPin { ... }

impl HSM {
	
	/// Tries to load a HSM and returns an implementation of 
	/// [`HardwareSecureModule`]. 
	pub fn load(path : P) -> Result<impl HardwareSecureModule, HSMError>
		where P : AsRef<Path> { 
			// ...
	}
}

A listing of standard objects to interface with a HSM

/// Initializing an A
trait HardwareSecureModule {
	
	// Inner Error
	type Error;	
	
	/// Initializes the HSM with given PIN
	fn initialize<P>(&self, pin : P) -> Result<HsmState, Self::Error>
		where 
			P : HsmPIN;
		
	/// Execute an operation on the HSM
	fn execute<F,P,R>(&self, pin : P, operation : F) 
		where 
			P : HsmPIN, 
			F : FnOnce(HsmContext)-> Result<R, Self::Error>,
			R : AsRef<[u8]>;
		
	/// Unlocks an HSM
	fn unlock(&self, pin : P) -> Result<HsmState, Self::Error>;
	
	/// Locks an HSM
	fn lock(&self) -> Result<HsmState, Self::Error>;
	
		
	fn encrypt<O>() -> Result<O, Self::Error>;
	
}

---

HSM shall be accessible via the HardwareSecureModule trait and ressembles similar functionality from the pkcs11-crate for rust.

Integration Layer

The integration layer represents the interface between the code, that will actually make use of an HSM or software based protection.

/// The DefaultKeyProvider is the current software based 
/// implementation using non-contiguous data types
struct DefaultKeyProvider { }

/// KeyProvider shall be factored out as trait to be implemented by either by the ['DefaultKeyProvider`] or by any Hardware
trait KeyProvider : Sized {
	type Error;	
	
	/// initialization function to load an in-memory nc based key provider
	/// from a password
	fn try_from_password<P>(pwd : P) -> Result<Self, Self::Error> where  P : 			AsRef<[u8]>;
	
	/// Unlocks the inner secret. 
	fn unlock(&self) -> Result<Buffer<u8>, Self::Error>;
		
	/// Tries to load a KeyProvider with a HSM
	fn with_hsm<H>(hsm : H) -> Result<Self, Self::Error> where H : HardwareSecureModule;
}

Here the KeyProvider is represented as a trait, which should be implemented on specific hardware focused KeyProvider types. We also supply a DefaultKeyProvider as a fallback to software based protection.

Threat Modeling

For a-priori analysis of possible threat vectors we use the STRIDE methodology.

Attack	Desired Property	Remediation
Spoofed	Authentication
Intercept PIN to unlock HSM		Minimize exposure time of reassembled pin by boojum scheme
Read out smart pointers to boojum scheme fragments		randomize smart pointer addresses
Tampered	Integrity
The HSM has been tampered with		Chose a tamper resistant HSM.
Repudiated	Non-repudiation
Repeated tries to unlock the snapshot file		Repudiation must be taken care of an integrating application by using audit and/or access logs to record access to any subsystems
Information Disclosure	Confidentitality
HSM PIN can be intercepted via side channel attacks		Minimize the exposure time of the HSM PIN
Denial Of Service	Availability
Too many requests to open a HSM will render it unresponsive		Introduce rate limiting on how many concurrent processes can access a HSM. This might incur a bottleneck on those systems integrating Stronghold with continuous persistence
Elevation Of Privileges	Least privilege
Stronghold running in an application with elevated privileges does not grant extra permissions on additional resources		The authentication mechanism for the HSM is not affected by elevated privileges

Drawbacks

HSM integration into Stronghold is to be seen as an additional layer of security and wide-spread token support through a standardized interface. As long as future HSM will support standard APIs like PKCS#11

Rationale and Alternatives

Extending Stronghold with HSM integration, while keeping the user interface modular will improve the usage and integration of Stronghold on a more secure level regarding tightened local security. It is virtually impossible to read out secret data from a HSM without physical accesss.

Prior art

The integration of HSM into Stronghold is currently a unique approach, combining software and hardware based protection for sensitive data. Similar works exists as Memguard, or PARSEC. Stronghold tries to combine both approaches.

Unresolved Questions

• What parts of Stronghold shall be secured by a smartcard?
• How shall the smartcard abstraction fill in as a secure backend?
  • Could the smartcard be part of the keyprovider?
• How would a secure backup of private keys for recovery look like?
• What boundaries exists for HSM and what key algorithms are supported?
• What minimum requirements do we want to provide in terms of cryptographic procedures?
• How to unlock the HSM sequence with protected PIN?
• How to execute procedures with a minimal attack surface?

Future Possibilities

Support for Platform based security extensions like ARM TrustZone, Intel SGX, Apple Secure Enclave etc.

Resources

• https://github.com/mheese/rust-pkcs11
• https://github.com/mbrossard/pkcs11/blob/master/src/cryptoki.c
• https://github.com/tpm2-software/tpm2-pkcs11/blob/master/docs/INITIALIZING.md
• https://security.stackexchange.com/questions/126715/tpm-2-0-pkcs11-on-windows-and-linux?rq=1
• https://developer.arm.com/documentation/102418/0101/TrustZone-in-the-processor
• https://salsa.debian.org/rousseau/PCSC/-/blob/master/README.md
• https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/6n4f2qhp5/index.html
• ERROR:tcti:src/tss2-tcti/tcti-device.c:319:Tss2_Tcti_Device_Init() Failed to open device file /dev/tpm0: No such file or directory tpm2-software/tpm2-tss#1408 ( dbus error on linux )
• https://github.com/PrateekJoshi/PKCS11/blob/master/main.c
• http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html#_Toc416959686
• https://github.com/mheese/PKCS11-SPECS
• https://github.com/mheese/rust-pkcs11/tree/master/pkcs11-docs
• https://google.github.io/tpm-js/
  https://www.slideshare.net/BrandonArvanaghi/practical-trusted-platform-module-tpm2-programming
• https://github.com/starlab-io/docker-tpm2-emulator
• https://github.com/starlab-io/tss-sapi
• https://www.youtube.com/watch?v=XwaSyHJIos8
• https://github.com/irtimmer/tpm2-pk11/wiki/Create-TPM-key
• https://azure.github.io/iot-identity-service/pkcs11/tpm2-pkcs11.html
• https://www.w3.org/TR/webauthn/
• https://github.com/OpenSC/OpenSC/wiki
• https://msdn.microsoft.com/en-us/library/windows/hardware/dn631754%28v=vs.85%29.aspx
• https://medium.com/swlh/demystifying-arm-trustzone-for-microcontrollers-and-a-note-on-rust-support-54efc62c290
• https://www.microsoft.com/security/blog/2018/06/05/virtualization-based-security-vbs-memory-enclaves-data-protection-through-isolation/
• https://doc.rust-lang.org/beta/unstable-book/language-features/abi-c-cmse-nonsecure-call.html
• https://riscv.org/blog/2021/10/zaya-now-offers-trusted-execution-environment-for-risc-v-zaya/
• https://github.com/fortanix/rust-sgx
• https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story

Standards And Integrations

• WebCrypto
• PKCS#11
• PARSEC

---

TODO

• Trusted Platform Module exploration
• HSM / SmartCard exploration
• CPU Enclaves support (ARM TrustZone)