Cryptography and Secure Health Data Exchange
Cryptography questions test correct primitive selection, key management, and secure exchange of health data. eHealth exchanges FHIR resources, DICOM images, referrals, and messages across organisational boundaries.
Core rules
Use AES-GCM, or AES-CBC with integrity protection, for data at rest; use TLS 1.3 for data in transit. Asymmetric cryptography such as RSA or ECC handles key exchange and signatures; hashing with SHA-256 or SHA-384 provides integrity, not confidentiality. Password storage uses Argon2id, scrypt, or PBKDF2 with salts. PKI issues and validates certificates; mTLS authenticates both ends. Key management uses an HSM or KMS, envelope encryption, rotation, and separation of duties. Never build your own cipher. Tokenisation can replace sensitive identifiers while preserving format.
Exchange patterns
FHIR APIs should require OAuth 2.0 and TLS. DICOM can use TLS and signed manifests. Direct messaging uses S/MIME and certificates. For cross-organisation exchange, agree on the trust framework, certificate authorities, and key custody. Signatures provide non-repudiation but do not encrypt.
Worked example
Two hospitals exchange a FHIR Bundle containing a discharge summary. They use TLS 1.3 with mTLS, OAuth 2.0 client credentials scoped to the patient, and a detached JWS signed with the sender's private key. Sensitive fields are encrypted with a data key, which is wrapped by the recipient's public key. The recipient verifies the signature, decrypts the data key in its KMS, and logs the exchange. Reasoning: TLS protects the channel; the signature proves origin and integrity; envelope encryption protects data at rest and limits key exposure.
Traps
ECB mode or static IVs. Hard-coded keys in apps. Using hashing as encryption. Accepting expired or self-signed certificates. Forgetting key rotation and revocation. Assuming TLS protects stored data.