Appointment Encryption OpenReception

Overview

This document describes a secure, post-quantum-resistant encryption system for appointment booking between patients and medical practices.

The system is based on Crystals-Kyber for asymmetric and AES-256 for symmetric encryption.

Core Principles

• Zero-Knowledge: The practice only sees appointment timestamps; all other data is encrypted until decrypted by a practice staff member with valid access or the patient.
• Post-Quantum Security: Using Kyber provides protection against future quantum computers. The algorithm is also computationally efficient enough not to overburden older access devices.
• User-Friendliness: Patients receive access to their appointments via a 6-8 digit PIN. Through private key splitting, we achieve a high level of protection despite simple access.
• Flexibility: We use hardware keys and passkeys for practice staff. Additional access permissions can be integrated into the system, which then makes necessary adjustments to existing data/encryption.
• Fault Tolerance: Multiple decryption options are available. This ensures that access to the system is not lost and, after thorough verification, new access can be established for a patient who has forgotten their PIN.

Architecture Overview

The following diagram shows the information flow and the encryption mechanisms in place.

graph LR
    Patient["Patient (PIN)"] <--> Appointments["Encrypted Appointments"] <--> Practice["Practice (Hardware-Key/Passkey)"]

    Patient --> Shamir["Shamir 2-of-3<br>Shares"]
    Appointments --> AES["AES-256 Session Key<br>+ Kyber-Encryption"]
    Practice --> Kyber["Kyber Keypairs<br>per Person/Hardware"]

Data Encryption

Data records are symmetrically encrypted on the server with an AES-256 key - the key is unique for each appointment. This key is then encrypted once for both practice and patient using their public keys, making it accessible only to the practice and the patient.

Patient Encryption

For patients, we use an approach that enables the highest possible user-friendliness without having to store unencrypted patient data centrally.

Key Management with Shamir Secret Sharing (2-of-3)

For each patient, we generate a keypair for asymmetric encryption. We split the private key into 3 shares, of which 2 are sufficient for decryption. One share is stored on the server, another is derived from the user's PIN. The third share can be kept in browser storage, for example, to grant the user easier access after initial verification.

Share Functions

• Share A (PIN-derived): Reproducible from PIN + PatientID, not stored
• Share B (Server): Encrypted on server, rate-limited access
• Share C (Browser): Locally stored for faster access

Private key reconstruction is thus possible for the following scenarios:

1. New device: PIN + Server-Share (A + B)
2. Known device: PIN + Browser-Share (A + C, faster)
3. Server offline: PIN + Browser-Share (e.g., to decrypt locally stored appointments)

Patient Identification

Although we don't maintain session management and don't want to store direct user data on the server, we still need to ensure some reconstructability so that patients can access multiple appointments without effort. For this, we use:

• Primary: PatientID - Hash (Argon2) of email address (reusable for multiple appointments)
• Secondary: 6-8 digit PIN for key activation
• iCal Integration: PatientID is embedded in calendar entries

Practice Encryption

For practices, we use a different approach. Practices need access to a larger number of appointments, and typically a larger group of people is authorized for access.

Key Architecture

• One keypair per person or hardware key (not per workstation)
• Flexible Authentication: Hardware tokens (YubiKey) or passkeys
• Granular Permissions: Different access rights depending on role

YubiKeys can be used to authenticate workstations independently of specific persons without the person entering the passkey themselves. Additionally, we offer the possibility to decrypt appointments on a person- and device-specific basis through passkeys.

Appointment Encryption

Encryption Flow

1. Session Key: Random AES-256 key per appointment
2. Data Encryption: Appointment data encrypted with session key
3. Key Encryption: Session key encrypted for patient + all practice keys
4. Storage: Only encrypted data + timestamp (unencrypted)

Key Management

Adding new patient keys happens automatically and is relatively unproblematic, as these always relate to one or more specific appointments of a patient. When new keys are generated for a practice (new staff member), all appointments must be updated. Using an existing key, all session keys of the appointments are determined and re-encrypted with the new key to grant it access to the appointments as well.

Removing Practice Keys

As long as at least one practice key remains, removing a practice key is straightforward. The key and all associated session keys are deleted, causing the key to lose all access rights.

Recovery Process for Patients

If a patient forgets their PIN, a recovery process must be initiated (this usually requires personal identification of the patient by the practice to remain compliant with data protection regulations). In this case, all of the patient's appointments are identified, decrypted by the practice, and re-encrypted with a new patient keypair. This is previously provided with the patient's desired PIN (the patient receives a magic link or QR code where they can set their new PIN). The patient's old keypair is then deleted.

Technical Security Measures

The following technical security measures appear sensible and can be evaluated based on the concept.

PIN Security

• Argon2id with high parameters (memory=64MB, iterations=10)
• Rate-Limiting on server (max 3 attempts/hour)
• Fixed Salt (PatientID) for reproducibility
• Share-based Security protects against brute-force attacks

Server Security

• No Clear Data except timestamps
• Encrypted Key Shares
• Audit Logs for all access
• Rate-Limiting for all authentication operations

Post-Quantum Security

• Crystals-Kyber for all asymmetric operations
• AES-256 for symmetric encryption
• Forward Secrecy through session keys per appointment

Further Implementation Notes

The following ideas should be considered during implementation:

Performance Optimizations

• Batch Processing for key updates (new practice key)
• Browser Caching of Share C for returning users
• Lazy Loading of appointment data in the practice
• Background Jobs for automatic key propagation

User-Friendliness

• iCal Integration with embedded PatientID
• Passkey Support for technically savvy users (as alternative to PIN)
• Hardware Tokens or Passkeys for practice staff
• Automatic Key Rotation in the background

Scalability

• Modular Structure for easy extensions
• Flexible Authentication (PIN, Passkey, Hardware Token)
• Granular Permissions depending on user role can be considered for practices
• Horizontal Scaling through session key architecture

Summary of This Concept's Advantages

1. Zero-Knowledge for Practice: Patient data remains protected even in case of server compromise
2. Device Independence: Patients can access their appointments from anywhere
3. User-Friendly PIN: 6-8 digit PIN is understandable for all users
4. Post-Quantum Security: Protection against future quantum computers
5. Forward Secrecy: Each appointment has its own session key
6. Fault Tolerance: 2-of-3 secret sharing allows loss of one share
7. Flexible Practice Integration: Hardware keys and passkeys according to preference
8. Scalable Key Management: Easy addition/removal of practice staff

Technical Specifications for Cryptographic Algorithms Used

• Asymmetric Encryption: Crystals-Kyber (Post-Quantum)
• Symmetric Encryption: AES-256-GCM
• Key Derivation: Argon2id (memory=64MB, iterations=10)
• Secret Sharing: Shamir's Secret Sharing (2-of-3)
• Authentication: WebAuthn (Passkeys), FIDO2 (Hardware Tokens)
• Hashing: SHA-256 for identifier derivation
• Session Keys: 256-bit random keys per appointment