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.

For more theoretical background and a basis for this work take a look at

L. Petzi, A. Dmitrienko, and I. Visconti, "PUF-Based Authentication in IoT Against Strong Physical Adversary Using Zero-Knowledge Proofs," 2024 IEEE Security and Privacy Workshops (SPW), San Francisco, CA, USA, 2024, pp. 312–319. doi: 10.1109/SPW63631.2024.10918871

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. Authentication can occur via PUF_TA_verify_ZK_proofs or the example scripts from scripts/proofs.

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

PUF_TA_verify_ZK_proofs

This function is provided as a PoC of device-to-device authentication. It allows for two devices running the TA to authenticate each other as the second factor.

To verify device the following equation must hold true

$$ g^v \cdot h^w = g^{r+\alpha R_1} \cdot h^{u+\alpha R_2} = g^r \cdot g^{\alpha R_1} \cdot h^u \cdot h^{\alpha R_2} = P \cdot (g^{R_1} \cdot h^{R_2})^{\alpha} = P \cdot \textit{COM}^{\alpha} $$

The function takes values generated by prover and returns TEE_SUCCESS if the equation holds.

For the security model this function doesn't have to run in the secure world but is provided for clarity.

The struct with all necessary values needs to be provided in a specific order as a memory reference due to nature of TEE communication.

typedef struct {
    uint8_t g_x[32];
    uint8_t g_y[32];
    uint8_t h_x[32];
    uint8_t h_y[32];
    uint8_t COM_x[32];
    uint8_t COM_y[32];
    uint8_t P_x[32];
    uint8_t P_y[32];
    uint8_t v[64];
    uint8_t w[64];
    uint8_t n[64];
} zk_proofs_mem_struct;

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)
PUF_TA_verify_ZK_proofs	0x33445566	zk_proofs_mem_struct (TEE_PARAM_ATTR_TYPE_MEMREF_INPUT / 448 bytes)	- (TEE_PARAM_ATTR_TYPE_NONE / 0 bytes)	- (TEE_PARAM_ATTR_TYPE_NONE / 0 bytes)	- (TEE_PARAM_ATTR_TYPE_NONE / 0 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.