Skip to content
Seald Healthcare SDK

The trust model

The SDK trusts one thing it did not receive over the network: the trust root built into the SDK. Before it acts, the SDK checks everything else against that trust root, or against a fingerprint pinned from it:

  • every device certificate (card)
  • every registration
  • every stored object

The trust root is built into the SDK

create fetches nothing. The trust root and the timestamp authorities’ roots ship inside the SDK itself. No environment variable, configuration file or network response can give your application a different root to trust. This matters because the SDK runs inside your application. If the trust root came from anywhere reachable at runtime, anything able to reach that path could choose what the SDK trusts.

The SDK verifies every card offline, for this tenant

A Card is a device certificate. The SDK checks every card it relies on offline against the trust root. This covers another device’s card, an identity authority’s card and its own card. The SDK needs no network round trip to decide whether to trust a card. The check also confirms that the card names this tenant. A card for a different tenant fails the check, like a card signed by an unknown authority. Either way, the operation that depended on the card fails with the error trust-failed.

The backup key fingerprint is pinned at the first session

The first time an application opens a session in a tenant, the SDK fetches that tenant’s backup key registration. It checks the registration against the trust root and pins its fingerprint. On every later session, the SDK compares against that pin. It does not look the key up again. A later backup key registration that names a different key fails with fingerprint-mismatch. The SDK refuses any backup key it cannot match to the one it verified the first time.

Decryption happens only on the device

Every decryption happens inside the SDK, on the device that holds the device key. The Seald Healthcare Cloud stores and moves stored objects and the recovery copies of key domain keys. It never holds a data encryption key and never sees plaintext. It passes on only ciphertext, from its own storage or from a customer’s bucket. See Plaintext lifetime for what your application does with the plaintext once the SDK hands it over.

The SDK checks every stored object before it trusts it

The SDK does not trust a stored object just because it decrypted. The SDK checks its full structure before it treats any of the content as real. A stored object fails with container-invalid when:

  • it is damaged
  • it belongs to a different object or version
  • its key does not open it

This applies to stored objects from the Seald Healthcare Cloud’s own storage and from a customer’s bucket the tenant has authorized.

Next