Skip to main content
Review and revision metadata
Review Date: 2026-07-05
Reviewer: Solution Architect

previous version on gdrive

A.8.24 Use of Cryptography

Control Objective​

Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented.

Policy Statement​

anDREa enforces mathematical confidentiality and integrity barriers across its primary environments to protect assets from unauthorized exposure or tampering. While cryptographic infrastructure for corporate Software-as-a-Service (SaaS) applications is outsourced to top-tier providers under strict supplier agreements, anDREa maintains rigorous verification procedures to monitor certificate lifecycles, key management lifecycles, and cloud-at-rest encryption configurations.

1. Development & Production Environment (myDRE Platform)​

The myDRE platform (*.mydre.org) operates entirely within Microsoft Azure, executing complete cryptographic coverage across all hosted data lifecycles:

  • Data-in-Transit Protection: All communication tunnels traversing the public internet or peering boundaries are encrypted using advanced transport security protocols. The SSL/TLS wildcard certificate for *.mydre.org is configured for automated renewal, backed by continuous uptime and expiration monitoring to flag renewal anomalies well before expiration.
  • Data-at-Rest Protection: By default, all Virtual Machine (VM) Operating System (OS) disks and secondary research data volumes are systematically encrypted-at-rest using Platform-Managed Keys (PMKs).
  • Encryption Verification: Verification is decentralized to maintain continuous compliance. Local Research Support Team (RST) members are required to audit environment health by tracking data-at-rest recommendations within the centralized Azure Advisor Score dashboard.

Key Management (myDRE)​

  • Outsourced Key Lifecycle: Key management actions for the myDRE environment are handled natively by Microsoft Azure's infrastructure.
  • PMK Architecture: PMKs are high-entropy encryption keys generated, rotated, stored, and managed entirely within Azure’s cloud hardware security modules (HSMs), preventing any local engineering exposure to raw key material.

2. Corporate Office Environment (Google Workspace)​

Corporate business and communication workflows (andrea-cloud.com) leverage Google's native distributed cryptographic framework:

  • Data Partitioning and Encryption: As data is written to disk within Google Workspace, it is fragmented into distinct data "chunks." Each individual chunk is independently encrypted-at-rest using the Advanced Encryption Standard cipher with a minimum AES-128 bit or stronger key configuration.
  • Access Control Lists (ACLs): Every data chunk is explicitly mapped to a specific system-level ACL, restricting decryption capabilities exclusively to authorized, cryptographically authenticated Google production services.

Key Management & Envelope Encryption (Google Workspace)​

Google Workspace utilizes a multi-layered hierarchical "Envelope Encryption" methodology to protect stored data chunks:

  • Chunk Key Wrapping: Each data chunk is encrypted with a unique Data Encryption Key (the Chunk Key). To secure this key, the chunk key is encrypted (wrapped) with a secondary master Wrapping Key managed by the global Google Key Management Service (KMS).
  • Storage Isolation: The resulting wrapped chunk key is stored directly alongside the encrypted data chunk payload. The underlying master wrapping keys reside exclusively within the isolated KMS memory boundary and are never stored in an unencrypted state.
  • Decryption Exchange Workflow: When an authorized application requests data, the storage service forwards the wrapped chunk key to the KMS. The KMS validates the requesting service’s cryptographic identity against production system ACLs. If authorized, the KMS decrypts the chunk key within its secure boundary and streams it back to the storage layer over an encrypted transit channel, allowing the storage block to reconstitute the file chunks.
  • Two-Factor Cryptographic Dependency: Data remains completely unrecoverable without the dual availability of both the storage-layer wrapped chunk key and the KMS-layer master wrapping key AES128 or stronger).

3. Alternative Third-Party Applications​

  • Supplier Mapping: A comprehensive ledger detailing the cryptographic postures, cipher standards, and digital certificates utilized across all other corporate SaaS applications is actively registered within the Record of Processing Activities (ROPA).
  • Periodic Certificate Compliance: The validity, suite strength, and expiration timelines of peripheral SaaS digital certificates are reviewed on a recurring basis, with verification tracking logs retained within the internal ticketing system (see: Record of Processing Activities (ROPA)).