Module 3 — Derived Digital Identities and Interoperability

I. Executive Summary

This module develops the concept of a derived digital identity as an extension of the root credential issued in previous modules. It establishes design principles, technical architecture, security controls, and interoperability mechanisms. In addition, it presents a Python implementation example, commented line by line, illustrating the generation of a derived identity using modern cryptographic algorithms, integrity through SHA-3, and ECDSA digital signatures. Integration with HSM/KMS and key life cycle management will be addressed in the next module.

II. Definitions and Scope

Root Credential: the master container, cryptographically protected, that stores biometric and demographic data of the subject.

Derived Identity: a digital instance linked to the root, generated with key derivation algorithms and protected by life cycle policies (usage, expiration, revocation).

Interoperability: the ability of a derived identity to be accepted in heterogeneous environments (PKI, JWT/COSE, RFID/NFC, transport, payments).

Scope of the module: generation, packaging, transport, and verification of derived identities, with emphasis on security and privacy.

III. Design Principles

Context separation: each derived credential must include unique, non-correlatable identifiers.

Restricted use policy: limited validity and functional scope defined at issuance time.

Cryptographic resilience: use of SHA-3-based key derivation functions and keys of at least 256 bits.

Biometric protection: avoid transferring templates; employ on-card compare mechanisms or robust symmetric encryption.

International compatibility: alignment with ISO/IEC 7816, ISO/IEC 14443, ISO/IEC 18000, X.509 profiles, and NIST recommendations.

IV. Proposed Architecture
[Root Credential] --(KDF SHA-3/HKDF)--> [Derived Key]
| |--> X.509 Certificate / JWT Token
| |--> HMAC Key for authentication
| |--> AES-GCM Key for biometric encryption

Main components:

Issuing Authority (Issuer/CA): signs and validates derived credentials.

Derivation Engine: executes HKDF-SHA3 with context and policy parameters.

Verifier (Relying Party): validates signature/certificate and applies expiration or revocation checks.

Audit/Revocation Service: maintains minimal traceability and invalidation mechanisms.

V. Technical Specification of Derivation
Inputs

Digest of the root credential.

Usage context (e.g., transport, payment, web authentication).

Random nonce.

Usage policies (TTL, scope, attributes).

Proposed Algorithm

Root Digest: SHA3-256(root_container)

Dynamic Salt: HMAC_SHA3(root_digest, Context || Nonce)

HKDF-SHA3:

PRK = HKDF-Extract(salt, root_digest)

OKM = HKDF-Expand(PRK, info=Context || Policy, L=64)

Derived Keys:

K_enc: AES-GCM 256 encryption

K_mac: HMAC-SHA3

K_sign: seed for ECDSA/P-256 or P-384

VI. Formats of Derived Credentials

X.509 v3: with specific extensions for rootHash, context, and validity.

JWT/CWT: for mobile and IoT environments, with standard claims and a derivation field.

Secure JSON Credential: portable package with encrypted attributes and digital signature.

VII. Security and Privacy

Ephemeral identifiers to avoid correlation.

Short-lived tokens reducing the need for revocation.

Active revocation through CRL/OCSP or token introspection.

Sensitive data protection with AES-GCM encryption and context-specific keys.

VIII. Python Example (Simulation without HSM)

-- coding: utf-8 --

"""
Module 3 — Example of derived identity (simulated)
Copyright © 2025 Antonio José Socorro Marín. All rights reserved.
Note: In production, private keys and signatures must be executed inside an HSM/KMS.
"""

import os, json, hashlib, hmac, time
from base64 import urlsafe_b64encode
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import jwt # pip install PyJWT

--- Simulated root data ---

root_container = b"ROOT_CONTAINER_SIMULATED"
context = b"MOB_TRANSIT"
nonce = os.urandom(16)
policy = {"ttl": 3600, "scope": "transit"}

Root digest with SHA3-256

root_digest = hashlib.sha3_256(root_container).digest()

Dynamic salt

salt = hmac.new(root_digest, context + nonce, hashlib.sha3_256).digest()

HKDF-SHA3 for derivation

hkdf = HKDF(algorithm=hashes.SHA3_256(), length=64, salt=salt,
info=context + json.dumps(policy).encode())
okm = hkdf.derive(root_digest)

K_enc, K_mac, seed = okm[0:32], okm[32:48], okm[48:64]

Generate ECDSA key pair (simulated)

private_key = ec.generate_private_key(ec.SECP256R1())
public_key = private_key.public_key()

Serialize public key

pub_pem = public_key.public_bytes(
encoding=serialization.Encoding.PEM,
format=serialization.PublicFormat.SubjectPublicKeyInfo
).decode()

Build derived token

now = int(time.time())
payload = {
"iss": "issuer.example.org",
"sub": f"derived:{urlsafe_b64encode(root_digest[:12]).decode()}",
"aud": "transit.provider",
"iat": now,
"exp": now + policy["ttl"],
"context": context.decode(),
"policy": policy
}

private_pem = private_key.private_bytes(
encoding=serialization.Encoding.PEM,
format=serialization.PrivateFormat.PKCS8,
encryption_algorithm=serialization.NoEncryption()
)

token = jwt.encode(payload, private_pem, algorithm="ES256")

Simulated biometric encryption

aesgcm = AESGCM(K_enc)
iv = os.urandom(12)
biometric = b"BIOMETRIC_TEMPLATE"
ciphertext = aesgcm.encrypt(iv, biometric, None)

credential = {
"token": token,
"public_key": pub_pem,
"enc_biometric": {
"iv": urlsafe_b64encode(iv).decode(),
"ciphertext": urlsafe_b64encode(ciphertext).decode()
}
}

with open("derived_credential.json", "w") as f:
json.dump(credential, f, indent=2)

print("Derived identity generated in derived_credential.json")

Comments

This example simulates the flow; in production, the private key must be generated and protected in an HSM.

SHA-3 is used as the base for HKDF, providing modern cryptographic strength.

The derived token (JWT) contains minimal claims and is signed with ECDSA.

Biometric data is encrypted with AES-GCM using a unique key.

IX. Operational Recommendations

Implement strict expiration and rotation policies.

Maintain encrypted audit logs with separation of duties.

Use ephemeral identifiers instead of permanent ones.

In sensitive contexts (payments, transport), prefer one-time or short-lived credentials.

X. Next Steps

In Module 4, HSM/KMS operations will be integrated, including:

Key generation and storage in secure hardware.

Use of PKCS#11 interfaces for signing and encryption.

Key life cycle policies.

Auditing of cryptographic operations.