Technical Whitepaper

This document covers the full technical architecture of iMegha. For a plain-English overview, see the main site pages.

1. Encryption

Algorithms

Key Hierarchy

• KEK Key Encryption Key -- derived from password via PBKDF2-SHA256. Never stored.
• DEK Data Encryption Key -- master key. Encrypted with KEK, stored on platform.
• FEK File Encryption Key -- unique per file. Encrypted with DEK or RSA. AES-256-GCM.
• CK Conversation Key -- unique per chat. Encrypted with DEK.
• FK Folder Key -- per shared folder. Encrypted with recipient's RSA public key.
• AK Album Key -- per shared album. Encrypted with recipient's RSA public key.
• AIK AI Conversation Key (Pro only) -- Encrypted with DEK.

Key Guarantees

• Every file gets a unique FEK -- compromise of one does not expose others
• Every conversation gets a unique CK
• Every IV is unique per encryption operation
• RSA used ONLY for key exchange, never bulk data
• DEK only exists in browser memory
• KEK derived on-the-fly, never stored or transmitted

2. Zero-Copy Sharing Protocol

Files are never copied to the recipient's cloud or to the platform. The file stays in the owner's S3 bucket at all times. Only the encrypted key travels.

1. Owner generates FEK, encrypts file with AES-256-GCM
2. Owner fetches recipient's RSA-2048 public key from platform
3. Owner encrypts FEK with recipient's public key (RSA-2048-OAEP)
4. Encrypted FEK + IV stored as share record in owner's DynamoDB
5. Recipient decrypts FEK with their RSA private key
6. Recipient downloads encrypted file from owner's S3 via pre-signed URL
7. Recipient decrypts file with FEK in browser

3. Infrastructure

Account Architecture

Cross-Account Security

The platform deploys infrastructure into user accounts via STS AssumeRole with a unique ExternalId per user (format: imegha-{uuid}). Temporary credentials expire after 1 hour. Permission boundaries restrict what the deployment role can do, even if the trust policy is broader.

Permission Boundary

CloudFormation

User Cloud uses a nested stack pattern. The master template orchestrates sub-stacks:

user-cloud.yaml (master)
  ├── storage.yaml    (S3 + KMS)
  ├── database.yaml   (DynamoDB)
  ├── iam.yaml        (Lambda roles)
  ├── api.yaml        (API Gateway)
  ├── monitoring.yaml (CloudWatch)
  └── services/
      ├── storage_service.yaml
      ├── sharing_service.yaml
      ├── imchat.yaml
      └── audit_service.yaml

Lambda Runtime

• Runtime: Python 3.12
• Default memory: 256 MB
• Default timeout: 30 seconds

4. Threat Model

5. Data Residency

Complete separation between user content and platform metadata. The platform never stores or processes user content.

6. AWS Cost Breakdown

Each user pays their own AWS bill directly. No markup from iMegha. Costs depend on usage.

7. Regulatory Compliance

The architecture natively satisfies requirements from multiple regulatory frameworks. When the platform cannot read user data, most compliance requirements are met by default.

GDPR (EU General Data Protection Regulation)

CCPA (California Consumer Privacy Act)

• Right to Know (Sec. 1798.100): Audit trail stored in user's own cloud — every share, view, and access event logged with timestamps.
• Right to Delete (Sec. 1798.105): User deletes CloudFormation stack. Platform data reduced to email and locked keys. Full deletion of content immediate.
• Right to Opt-Out (Sec. 1798.120): No data sale possible. Platform cannot read user data. Zero-knowledge architecture prevents data monetization.

HIPAA (Health Insurance Portability and Accountability Act)

Note on BAAs: Because iMegha operates on a zero-knowledge basis and patient data never passes through or is stored on the platform, the typical BAA requirement is architecturally mitigated. The platform cannot be a business associate if it cannot access PHI.

SOX & Financial Compliance

• Audit Trail: Immutable access log in user's DynamoDB with timestamps, event types, and actor IDs.
• Data Integrity: AES-256-GCM authentication tags provide cryptographic proof of data integrity.
• Access Controls: Per-file sharing permissions with instant revocation. All access events logged.
• Segregation of Duties: Platform (coordination) and user cloud (data) are architecturally separated. Neither can access the other's content.