Zero-Knowledge PUF CROSSCON HV Demo

This repository contains a proof-of-concept Trusted Application for authentication using a Physical Unclonable Function (PUF) combined with zero-knowledge proofs.

The application's trust model is backed by the CROSSCON Hypervisor, which provides isolation and integrity. A subset of the GlobalPlatform Core and Client APIs has been implemented to enable structured communication and improve portability.

Note: This app uses Zephyr RTOS and not a full-featured TEE like OP-TEE/MTower. At the time of starting this project no TEE was available for the platform.

Building/Usage

The application can be used as a standalone demo via the lpcxpresso55s69/lpc55s69/cpu0 target when building with west. However, it is primarily intended to be run as part of crosscon/UC1.1-Manifest.

Available functions

PUF_TA_init

Has to be called before other functions. Initializes PUF hardware and neccessary ECC variables as well as returns $g$ and $h$.

PUF_TA_get_commitment

Internally produces responses $R_1$ and $R_2$ in response to challenges $C_1$ and $C_2$ using the device's PUF. Commits $R_1$ and $R_2$ using Pedersen commitment into $\textit{COM}$ and returns it.

$R_n = \textit{SHA256}(\textit{SHA256}(\textit{PUF Response}, \textit{Trusted Application UUID}), C_n)$

Additional hashing with TA UUID serves as a PoC of identity scoping that could happen in a true multi-tenant TEE. This mitigates the risk of some TA compromising platform via misuse or exfiltration of the physically unique secret.

$\textit{COM} = g^{R_1} \cdot h^{R_2}$

$\textit{COM}$ can be stored in a public database as it doesn't disclose any information on $R_1$ / $R_2$ or device's PUF response.

Multiple $\textit{COM}$ can be created using different pairs of $C_1$ / $C_2$.

It's crucial that $C_1 \neq C_2$.

PUF_TA_get_ZK_proofs

Once the device is enrolled, it can use this function to authenticate itself to other devices. The process is initiated by the verifier, which sends challenges $C_1$ and $C_2$ , along with a nonce $n$. The nonce ensures the freshness of the authentication process and prevents the replay of old or recorded protocol runs.

Two random values $r$ and $u$ are created which then formulate a commitment $P=g^r \cdot h^u$.

This is used to create a hash $\alpha = \textit{SHA256}(P, n)$.

Two zero-knowledge proofs are calculated, denoted as $v$ and $w$, where $v = r + \alpha R_1$ and $w = u + \alpha R_2$ . These proofs enable to demonstrate knowledge of $R_1$ and $R_2$ to the verifier, without disclosing the actual values of $R_1$ and $R_2$.

$P$, $v$ and $w$ are returned by the function.

These along with saved $\textit{COM}$, $g$, $h$ and $n$ can be used to authenticate device. Example scripts for this purpose are available in scripts/proofs.

For more info on how to proof/authenticate take a look at scripts/proofs/README.md

API

GP Client

The app uses a subset of Global Platform Client API for communication.

An example of client-side communication can be seen at GUEST_VM0 branch.

TA UUID - 0x00112233445566778899AABBCCDDEEFF

Handler	Function ID	Parameter 1 (atrr/b)	Parameter 2 (atrr/b)	Parameter 3 (atrr/b)	Parameter 4 (atrr/b)
PUF_TA_init	0x00112233	$g_x$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)	$g_y$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)	$h_x$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)	$h_y$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)
PUF_TA_get_commitment	0x11223344	$C_1$ (TEE_PARAM_ATTR_TYPE_MEMREF_INPUT / 32 bytes)	$C_2$ (TEE_PARAM_ATTR_TYPE_MEMREF_INPUT / 32 bytes)	$\textit{COM}_x$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)	$\textit{COM}_y$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 32 bytes)
PUF_TA_get_ZK_proofs	0x22334455	$C_1$ / $P_x$ (TEE_PARAM_ATTR_TYPE_MEMREF_INOUT / 32 bytes)	$C_2$ / $P_y$ (TEE_PARAM_ATTR_TYPE_MEMREF_INOUT / 32 bytes)	$n$ / $v$ (TEE_PARAM_ATTR_TYPE_MEMREF_INOUT / 64 bytes)	$w$ (TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT / 64 bytes)

GP Core

This app implements a subset of Global Platform Core API for potential modularity portability of the authentication scheme. This is aligned with the TRL 3/4 research nature of the project and is not intended as full GP compliance.

Category	GP Feature/API	Status
BigInt Arithmetic	TEE_BigInt* ops (Alloc, Add, Mul, Mod, Convert)	Implemented
	TEE_BigIntSub, ExpMod, etc.	Not Implemented
Digest / Hashing	TEE_Digest* (SHA-256)	Implemented
	Other hash functions (SHA-1, MD5, SM3)	Not Implemented
Symmetric Crypto	AES, 3DES, SM4, Cipher API	Not Implemented
MAC / HMAC	HMAC, CMAC APIs	Not Implemented
Asymmetric Crypto	RSA, DSA, DH	Not Implemented
	EC arithmetic (TEE_ECPoint, TEE_ECCurve)	Custom Helper Types Only
Key Management	TEE_AllocateTransientObject, TEE_SetOperationKey	Not Implemented
Randomness	TEE_GenerateRandom	Implemented
Time Functions	TEE_GetSystemTime, TEE_Wait	Not Implemented
Session Management	TA_OpenSessionEntryPoint, etc.	Partial
Error Codes	TEE_Result, TEE_ORIGIN_*, TEE_ERROR_*	Implemented
Object APIs	Persistent objects, secure storage	Not Implemented

Additional Information

$\textit{COM}$, $g$, $h$ and $P$ are Eliptic Curve Points derived from Mbed TLS's mbectls_ecp_point. To reconstruct the MbedTLS compatible byte sequence a byte with value 0x04 needs to be prepended. The final structure thus should look like 0x04||X||Y.

Demo's

Running

Proof

Debug output

License

See LICENSE file.

Acknowledgments

The work presented in this repository is part of the CROSSCON project that received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101070537.