Encrypt Don't Trust: Securing Palm Vein Biometrics from Sensor to Access Control Server

An in-depth technical analysis explores how to protect palm vein biometric data in access control systems using a security-by-design approach. The article emphasizes that biometric templates cannot be changed like passwords, making robust protection essential against physical theft, insider threats, and presentation attacks. It details the application of Zero Trust principles, minimizing the Trusted Computing Base, and implementing hardware roots of trust such as Secure Boot and encrypted non-volatile memory. Russian regulatory requirements including 152-FZ, Government Decree No. 1119 for data protection levels, FSTEC Order No. 21, and FSB Order No. 378 are mapped directly to technical controls like mTLS, OSDP v2.2, and liveness detection. Threat actor profiles ranging from external attackers to privileged insiders are analyzed with specific countermeasures for each segment of the data path. The piece concludes that trust must be compressed to the hardware root, server room, and dual-operator registration process while everything else relies on verifiable cryptography and auditing.

HabrTranslated from Russian

Read at source

An experienced hardware and software engineer shares lessons from evaluating a commercial palm vein biometric access control system, focusing on the critical challenge of protecting biometric templates throughout their lifecycle from sensor to server.

The system uses proprietary convolutional neural network algorithms to capture, process, and match palm vein patterns. Because biometric data cannot be reset like passwords or certificates, any compromise of high-quality templates could require surgical intervention that is currently available from only one or two teams worldwide.

Regulatory and Standards Framework

Design follows IEC 24745:2022 requirements for irreversibility, revocability, and unlinkability of biometric templates, verified according to ISO/IEC 30136. In Russia, compliance centers on 152-FZ Article 10 for separate biometric consent, Government Decree No. 1119 defining protection levels up to UZ-2, FSTEC Order No. 21 for technical measures, and FSB Order No. 378 for certified cryptographic modules.

The mandatory path includes threat modeling per FSTEC methodology, development of a protection specification, implementation of controls, and final certification by licensed laboratories.

Zero Trust Architecture and Data Path

Three trust zones are defined: the physically secured server room, the building LAN where terminals operate, and the completely untrusted passage area. Each terminal must function autonomously with a local cache, making encryption of stored templates and hardware-protected keys mandatory.

Only the optical sensor module itself is treated as an irreducible trusted component; all other elements rely on verifiable mechanisms such as AES-256 or GOST Kuznechik encryption, ECDSA signatures, mTLS with per-device certificates, and Secure Boot rooted in ROM.

Threat Actors and Controls

  • N1 External: MitM, packet injection, and presentation attacks countered by liveness detection and encrypted channels.
  • N2 Local Physical: Device theft and JTAG extraction countered by encrypted NVM, non-extractable keys in secure elements, and limited cache scope.
  • N3 Insider: Administrator or registration-operator compromise countered by signed releases, dual-control registration, MFA, SIEM, and closed VLAN segmentation.

Executive commands to locks use OSDP v2.2 with encryption, while registration requires token-based dual-operator confirmation.

The resulting architecture reduces the trusted computing base to the hardware root inside each terminal, the server room perimeter, and the small circle of registration operators, with all other components protected by cryptography, signatures, or audit logs.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Policy & Regulation

Russian Minister Proposes Blocking All SIM Cards Linked to Fraudsters Banned in MAX Messenger
Russia Ready to Disclose Source Code of Social Networks, Messengers and AI Models
Russia Mulls Mandatory Two-Week IMEI Registration for Foreign Smartphones via Gosuslugi