Skip to main content

Hash Maps and Network Fingerprints

The DSM includes several supporting mechanisms that ensure data integrity, device verification, and privacy-preserving references throughout the sharing workflow.

Hash maps​

When node identifiers and other sensitive values are hashed for sharing (see Instances and Instance Nodes), the system needs a way for authorised parties to reverse those hashes when needed. The hash map provides this reversible mapping between hash values and their originals.

How it works​

Each hash map entry stores:

  • The hash value — the hashed identifier that appears in shared data
  • The mapped value — the original value the hash represents
  • A validity window — start and end dates that define when the mapping is active

The hash value itself is the lookup key, answering the question: "given this hash, what was the original value?" This is needed when decrypting shared data or resolving hashed node references back to their source.

Access model​

Hash map entries are broadly readable within a tenant. This permissive access is intentional — any party involved in a sharing workflow may need to resolve hashes to complete the decryption process. Restricting access would break the data sharing flow.

Network fingerprinting (JA4)​

The DSM tracks JA4 fingerprints as part of the data sharing workflow. A JA4 fingerprint is a cryptographic signature of network and TLS characteristics that identifies communication patterns and client profiles during sharing interactions.

How JA4 fingerprints work​

JA4 fingerprinting captures:

  • TLS session details — cipher suites, supported extensions, and handshake characteristics
  • HTTP/2 settings — frame types and settings negotiation
  • Browser and client signatures — a standardised way to identify client software and configuration

These characteristics are hashed into a compact, stable identifier that can be used to:

  • Detect spoofing — identify when an attacker is attempting to impersonate a legitimate client
  • Cross-session detection — recognise when the same client appears across multiple sharing events
  • Audit trail — record the client profile used for each sharing interaction

Unlike fingerprints based on volatile browser properties, JA4 focuses on cryptographic properties that remain stable across sessions and updates.

Temporary verifications​

During document processing — such as when an identity document is being scanned, OCR-processed, or cross-referenced against external databases — intermediate results are stored in a temporary verification area. This holds the extracted data while the verification pipeline completes its work. Once verification is finished, the results are promoted to permanent storage as nodes, instance nodes, or events.

How these components support data integrity​

Together, these mechanisms create a multi-layered integrity model:

  1. JA4 fingerprints answer "which client signature and TLS profile was used to submit this?"
  2. Temporary verifications answer "what was in the submitted documents?"
  3. Hash maps answer "what do these privacy-preserving references resolve to?"

The core sharing workflow (instances and nodes) handles what was shared, while these supporting components handle the how (which client), the verification (is the data genuine), and the privacy (hashed references).