What is BioAffix Mul-Sec?

BioAffix Mul-Sec is an encryption protocol developed by Ones Technology and is currently in active use within the BioAffix infrastructure. It establishes an application-specific second TLS tunnel (“TLS-in-TLS”) inside the standard TLS/SSL tunnel within the client-server communication chain. This ensures that application data remains opaque in scenarios involving OS-level TLS interception/MITM/debugging and TLS offload/inspection at the load balancer. A package ID feature mitigates the risks of replay attacks and fraudulent clients. The inner tunnel is sustained by a root of trust that is independent of the Operating System’s Root Certificate Store and is established using short-lived certificates regenerated for each session. As a result, critical identity and access operations are protected with end-to-end confidentiality and authentication.

BioAffix Mul-Sec was developed by Ones Technology during the implementation of the Biometric Access Control Systems for the Social Security Institution. It is a communication protocol designed to prevent the capture of biometric and sensitive data, addressing risks posed by malicious internal personnel on the server/data center side or even by the employees who code and develop the system during the process of collecting the biometric data of all citizens. Following the practical observation of visibility risks created by corporate CA injection, TLS offload, and client-side debugging tools, Mul-Sec has closed this gap with an application-level, per-session TLS-in-TLS approach.

Terminology

• TLS/SSL: Technically refers to TLS 1.2/1.3.
• Outer Tunnel (Outer TLS): The standard tunnel managed by the browser/OS library, established with standard x.509 certificates. This tunnel can be terminated at the Load Balancer.
• Inner Tunnel (Inner TLS / Mul-SEC Tunnel): The second tunnel operating within the application, established based solely on the Mul-SEC root of trust and the compile-time signature. It uses short-lived (ephemeral) certificates/keys for each connection.
• Client: BioAffix Client Applications.
• Server: BioAffix Application Server, BioAffix OneServer.

Problem Definition: Scenarios Where Standard TLS Alone is Insufficient

Client-Side TLS Debugging

Applications that use TLS at the operating system level can be inspected via man-in-the-middle (MITM) attacks using tools like Fiddler / HTTPS Analyzer or by injecting a corporate root certificate. In such cases, data packets can be viewed or replayed.

TLS Offload / Inspection at the Load Balancer In high-traffic architectures, SSL/TLS may be terminated at the Load Balancer, its content inspected at L7, and then re-encrypted within the data center, often with a weaker or corporate CA. Malicious or over-privileged personnel can inspect incoming and outgoing data (Port mirroring – package mirroring).

These two situations compromise confidentiality. Especially if the “trusted certificate store” is managed by the device/OS, content can be read by accessing or installing an internal CA certificate.

Mul-Sec Design Principles

• Application-level confidentiality: Application data remains confidential within a second tunnel even if the outer TLS is decrypted.
• Compile-time root of trust: The inner tunnel’s trust is established through the application’s signature and the Mul-Sec embedded root key; it is independent of the operating system’s root store.
• Per-session keys: The generation of short-lived certificates/keys for each connection makes reuse and replay attacks more difficult.
• Transparent topology compliance: Content remains opaque even in the presence of Load Balancer offload, reverse proxies, etc.
• Root of Trust (Root CA): Embedded within the software.
• Application Signature: It verifies the application signature; the inner tunnel is not established if it does not match the expected signature.
• Session Certificates: Single-use client and/or server certificates are created for each connection.

Security Features and Threat Mitigations

• Independence from the OS root store: The inner tunnel is established by trusting only the software-embedded root of trust; it remains ineffective even if a corporate CA is injected.
• Dual-layer encryption: Even if the outer TLS is decrypted, the application data remains encrypted in the second layer.
• Per-session key/certificate: The impact of a replay attack or key leakage is limited to a single connection.
• Compile-time signature verification: Only the expected application binary can open an inner tunnel; re-packaged or patched clients are blocked.
• Load Balancer: The content of the inner tunnel is not visible even if L7 inspection is active; only an encrypted byte stream is transported.

Note: Mul-Sec does not store traffic metadata (source IP, time, byte count, etc.) at the network endpoints; confidentiality lies within the application payload.

Policy Compliance

• KVKK/GDPR: Reduces the risk of data leakage during transmission with an additional encryption layer.
• ISO/IEC 27001 (A.8 Cryptography, A.5 Access Controls): Facilitates compliance with policy and technical control requirements.

Limitations

• Dual-layer encryption introduces a measurable overhead on CPU and latency. Typical impacts vary depending on packet size, handshake frequency, and hardware acceleration.
• Inner tunnel traffic cannot be inspected by L7 devices.

Frequently Asked Questions (FAQ)