Encryption Architecture: How, Where & What We Encrypt

ForensicBIM implements a defense-in-depth cryptographic architecture ensuring that customer data is never transmitted, stored, or processed in unencrypted form. The matrix below outlines how cryptographic controls are applied at each layer:

Every communication channel between user web browsers, client software, API endpoints, and sovereign regional processing infrastructure is strictly encrypted using modern Transport Layer Security:

• TLS 1.3 Mandatory Enforcement: All connections negotiate TLS 1.3 by default (with TLS 1.2 fallback for older corporate environments). Insecure legacy protocols (SSL v2/v3, TLS 1.0, TLS 1.1) and broken cipher suites are permanently disabled at the edge.
• Perfect Forward Secrecy (PFS): Ephemeral Diffie-Hellman key exchanges (ECDHE) ensure that session keys are temporary. Even in the theoretical compromise of a server private key, past historical session traffic cannot be decrypted retroactively.
• HTTP Strict Transport Security (HSTS): The web application broadcasts an HSTS header with a one-year duration (max-age=31536000; includeSubDomains; preload), enforcing encrypted HTTPS communication and preventing protocol downgrade attacks.
• Direct-to-Storage Signed Uploads: When large IFC models (up to 5Gb) are uploaded, client browsers receive short-lived cryptographically signed upload tokens. File bytes stream directly over encrypted HTTPS into the customer's sovereign regional storage bucket, eliminating unencrypted intermediate network hops.
• Secure Session Isolation: Application session cookies are configured with Secure, HttpOnly, and SameSite=Lax flags alongside a 60-minute idle session timeout, mitigating cross-site scripting and unauthorized session hijacking.

All persistent binary files and analysis deliverables are stored in hardened, geographically partitioned cloud storage buckets. This includes:

• Uploaded original Industry Foundation Classes (IFC) model files.
• Extracted 3D geometric meshes (GLB format).
• Rendered 3D perspective thumbnail previews (PNG format).
• 2D data density and property heatmaps (PNG format).
• Full algorithmic forensic audit reports (JSON format).

Envelope Encryption Mechanism: Every object written to regional storage is encrypted at rest using industry-standard AES-256 (Advanced Encryption Standard with a 256-bit key length):

• Before writing to physical storage media, files are divided into individual data chunks.
• Each chunk is encrypted using a unique, randomized chunk-level Data Encryption Key (DEK).
• The DEK is wrapped (encrypted) by an overarching Key Encryption Key (KEK) managed within a dedicated, audited Key Management Service.
• When an authorized process reads the file, the KEK unwraps the DEK in memory to stream the decrypted content to the authenticated worker job.

Non-binary metadata, audit ledgers, score matrices, and user configurations reside in enterprise NoSQL datastores configured with comprehensive encryption at rest:

• AES-256 Datastore Encryption: All database documents, table indexes, commit logs, and point-in-time backup snapshots are automatically encrypted with AES-256.
• Continuous Key Rotation: Root encryption keys are rotated on an automated schedule without requiring application maintenance downtime or database re-indexing.
• Tenant-Level Path Isolation: Storage rules and database access definitions strictly segment records by verified user identity. Client SDK direct write access to security audit logs is explicitly blocked at the rule level.

In accordance with SOC 2 Processing Integrity principles, ForensicBIM verifies and seals every uploaded model cryptographically to prevent silent file corruption, bit-rot, or unauthorized tampering:

• SHA-256 Cryptographic Digest: On upload ingest, the system calculates an authoritative 256-bit SHA-256 checksum across the raw IFC byte stream. This digest is immutably recorded in the analysis document and logged to the security audit trail.
• Composite CRC32c Checksums: Storage transfers and multi-part uploads utilize composite CRC32c error-detecting cyclic redundancy codes to verify byte-level transfer fidelity across network boundaries.
• Immutable Audit Traces: Every authentication, model upload, secret link issuance, permission change, and deletion event generates a tamper-evident audit record stamped with high-precision UTC timestamps and client IP addresses.

While ForensicBIM's standard AES-256 encryption at rest satisfies standard SOC 2 Type II and ISO/IEC 27001 audit requirements, select enterprise, defense, and governmental organizations require sovereign custody over their encryption keys.

For these organizations, ForensicBIM provides Customer-Managed Encryption Keys (CMEK) as an available option under the Enterprise subscription:

• Bring Your Own Key Architecture: Enterprise customers control the cryptographic root keys hosted within an isolated regional Key Management Service (KMS).
• Independent Key Lifecycle: The enterprise organization controls key creation, custom rotation schedules (e.g. 90-day automatic rotation), and granular IAM access policies.
• Cryptographic Shredding (Instant Revocation): If an enterprise customer needs to immediately revoke access to all stored assets, they can disable or destroy their KMS key in their console. Without the key, all stored data becomes instantly unrecoverable ciphertext across the storage medium.
• Independent Access Auditing: Every time ForensicBIM's regional processing workers decrypt an object to execute a valuation or geometry parse, an auditable event is recorded directly in the customer's security audit logs.

ForensicBIM adheres to a foundational project sovereignty rule: Storage, processing, and all cryptographic functionality remain strictly within the geographic region chosen by the user.

When you select a storage location, your file storage buckets, compute worker jobs, database documents, and cryptographic operations are executed strictly within that regional boundary. Data is never copied or processed cross-region:

Our cryptographic architecture aligns with the core requirements of AICPA SOC 2 Type II Trust Services Criteria and the ISO/IEC 27000 family:

AICPA SOC 2 Type II Trust Services Criteria

• CC6.6 (Boundary & Perimeter Protection): Strict Content Security Policy (CSP), TLS 1.3 termination, Uniform Bucket-Level Access, and secure HTTP headers defend against unauthorized perimeter access.
• CC6.7 (Data Transmission & Storage Encryption): Sensitive architectural data is protected at rest using AES-256 encryption and in transit using TLS 1.3/1.2 protocols.
• C1.1 & C1.2 (Confidentiality & Tenant Isolation): Confidential customer models are isolated by authenticated user ID namespaces with customer-controlled disposal and permanent deletion capabilities.
• PI1.1 (Processing Integrity): Cryptographic SHA-256 fingerprinting on upload verifies that input models remain unaltered throughout parsing, valuation, and reporting cycles.

ISO/IEC 27001:2022 Controls

• Control A.8.24 (Use of Cryptography): Formal cryptographic policy establishing AES-256 standards, key lifecycle governance, and support for Customer-Managed Encryption Keys.
• Control A.8.20 (Network Security): Secure communication channels utilizing TLS 1.3 with Perfect Forward Secrecy across all web and API layers.
• Control A.8.11 (Data Masking & Protection at Rest): Storage and database assets are encrypted prior to physical storage, with zero unencrypted disk footprint.
• Control A.5.23 (Information Security for Cloud Services): Cloud service tenant isolation, regional sovereign anchoring, and continuous audit verification.
• Control A.8.12 (Data Leakage Prevention): Strict bucket-level policies (UBLA & PAP) prohibiting unauthorized external sharing or cross-regional data movement.
• ISO/IEC 27701 (Privacy Information Management): User-controlled data residency guarantees supporting European GDPR, UK Data Protection Act, and international privacy mandates.