Segmented Key Patent

Overview

The international patent WO2018154258A1 describes a secure segmented key authentication system based on the distribution of a pairing key (K_pair) across multiple devices. The patent mentions NFC as an example of implementation, but the system can use different types of supports (HSM, software, hardware). This patent constitutes the technological foundation of the segmented key authentication engine implemented in CryptPeer®.

This innovation significantly strengthens authentication data security by:

• Distributing the pairing key across multiple segments stored on independent supports (hardware, software, cognitive, contextual);
• Performing root key recomposition only locally, in volatile memory, according to an authentication policy;
• Ensuring that the server can never derive encryption keys, even with all identifiers and the code;
• Storing sensitive data only in volatile memory (RAM), for a fraction of a second, then automatic erasure;
• Implementing a password obfuscation mechanism to counter keyloggers.

Note: The patent mentions NFC as an example of implementation, but the segmentation method is abstract and independent of any particular communication support. CryptPeer implements this segmentation with controlled local supports (software vault, user KDF, isolated modules, contexts), without dependency on NFC.

Key Advantages

How It Works

Segmented Key Model (Abstract, Support-Independent)

The patent defines an abstract segmented key model that does not presuppose any specific communication support (neither NFC, nor BLE, nor any other). The segmented pairing key (K_pair) is divided into several segments distributed across independent supports:

Recomposition Policy

A segmented authentication policy P is defined by:

• The subset of segments to require: S_P ⊆ S
• The imposed presentation order: e.g., (S2 → S1 → S3)
• The number of authorized attempts
• The maximum session validity duration
• The blocking / logical erasure rules in case of failure

This policy is managed by the segmented key authentication engine, which remains within the patented scope.

Root Key K_seg Recomposition

Recomposition is performed locally by the SegmentedKeyEngine on the user's terminal:

1. Policy selection: according to the policyId (e.g., "STD", "SENS", "CRIT")
2. Segment collection: in the order imposed by the policy, retrieval from their respective supports
3. Normalization: each segment is normalized in the form Zi = type_i || length_i || value_i
4. Input material construction: Z = Z1 || Z2 || ... || Zk
5. Mixing and derivation:
   • Pre-mixing hash: H = SHA3-512(Z || policyId || deviceContext)
   • Pairing key derivation: K_pair = HKDF_SHA3_512(H, policySalt, info, L)
   • Root key derivation: K_seg = HKDF_SHA3_512(K_pair, appSalt, "CryptPeer/RootKey", L)
6. Session management: K_seg is kept in volatile memory for at most sessionTTL, then erased

Key point: Only K_seg is returned to CryptPeer via the getRootKey(policyId) interface. The internal structure (segments, order, blocking rules) remains within the patented scope and is never exposed.

Encryption Key Derivation in CryptPeer

Once K_seg is obtained locally, CryptPeer uses it to derive operational keys:

• Conversation key v2: K_conv_v2 = HKDF(K_base_conv, salt=K_seg, info="CryptPeer/msg/v2", L=32)
  • The server cannot derive this key because it does not know K_seg
• File key v2: K_file_v2 = HKDF(K_file_base, salt=K_seg, info="CryptPeer/file/v2", L=32)
  • Same principle: without K_seg, impossible to recover K_file_v2

This architecture ensures that even if the server is compromised, it cannot decrypt messages or files, because it never has K_seg which requires local recomposition of segments according to the policy.

Countries Where the Patent is Granted

The patent WO2018154258A1 has been granted in the following countries:

Note: All issued patent numbers are indicated. The Algerian patent is under issuance.

Variants and Extensions

The patent covers several possible variants and extensions:

• Exclusive pairing: between the main device and the main token;
• Multiple records: multiple authentication records per token (labels);
• Microcontroller tokens: with physical protections (self-destruction, random erasure);
• Attempt limits: configurable security policies;
• Manual or automatic authentication: according to needs;
• Modular reuse: reuse of tokens/segments in other contexts.

Resources

To consult the full patent text and obtain more information: