ROMbsr Security Model

Hardware-backed key protection, zero-trust architecture, and comprehensive audit trails that exceed financial industry standards for Android ROM signing

Threat Model & Mitigations

ROMbsr is designed to protect against sophisticated adversaries who may have compromised your build infrastructure. Here's how we address each threat:

Threat 1: Compromised Build Server

Scenario: Attacker gains root access to build servers through supply chain attack or vulnerability.

Traditional Risk: CRITICAL - Signing keys on filesystem are immediately compromised.

ROMbsr Mitigation: SECURE
  • Signing keys never exist on build servers - they're physically isolated in HSM
  • Build servers can only generate signing requests, not signatures
  • Even with full root access, attacker cannot extract signing keys

Threat 2: Malicious ROM Injection

Scenario: Attacker attempts to sign and distribute a backdoored ROM version.

Traditional Risk: HIGH - If build server compromised, attacker can sign arbitrary ROMs.

ROMbsr Mitigation: SECURE
  • All signing requests include cryptographic hashes of artifacts
  • GitOps queue provides immutable audit trail of all signing operations
  • Signing policies can enforce additional verification before HSM access

Threat 3: Insider Threat

Scenario: Malicious insider with legitimate access attempts to exfiltrate keys or sign unauthorized builds.

Traditional Risk: HIGH - Single person with server access can compromise everything.

ROMbsr Mitigation: SECURE
  • Multi-level HSM authentication separates admin, signing, and backup roles
  • All operations logged with cryptographic proof - cannot be altered
  • Dual control can be enforced for critical operations

Threat 4: Supply Chain Attack

Scenario: Compromised dependency or build tool attempts to steal keys during build process.

Traditional Risk: CRITICAL - Build tools have access to signing keys.

ROMbsr Mitigation: SECURE
  • Build environment uses request capture - no real keys present
  • Signing happens in isolated environment with minimal dependencies
  • HSM operations use verified, minimal PKCS#11 interface only

Request Capture: Production Security Feature

A common misconception is that ROMbsr's request capture (libmock_pkcs11.so) is a development or testing feature. In reality, it's a critical production security component that enables the entire zero-trust architecture.

Why Request Capture is Essential for Security

Enables Key Isolation

By capturing signing requests instead of performing signing, build infrastructure never needs access to private keys. This is not a workaround - it's the fundamental security design.

Prevents Key Exfiltration

Even if attackers compromise the build server and modify libmock_pkcs11.so, they cannot extract keys that were never present. The worst they can do is corrupt the signing requests.

Enables Distributed Builds

Multiple build nodes can operate in parallel without any access to signing keys. All captured requests are processed centrally by the secure signing infrastructure.

Security Architecture: Request capture is not "mock" signing - it's deferred signing. The build process captures what needs to be signed, and the signing process applies real signatures later. This separation is what makes ROMbsr fundamentally more secure than traditional approaches.

Hardware Security Module (HSM) Integration

YubiHSM2 Security Features

Hardware Key Protection

Keys are generated inside the HSM and never exist in plaintext outside. Physical tampering triggers key deletion. FIPS 140-2 Level 2 certified hardware security.

Cryptographic Attestation

HSM can prove its identity and that keys were generated internally. Prevents key substitution attacks. Verifiable chain of trust from hardware to signature.

Role-Based Access Control

16 authentication keys with granular permissions. Separate roles for admin, signing, backup, and audit. Capabilities enforced by hardware, not software.

HSM Authentication Architecture

# Default YubiHSM2 Authentication Keys
Key ID 1: Factory Default (password: "password")
  - Used only for initial provisioning
  - Should be deleted after setup

Key ID 2: Administrator
  - Can create/delete objects
  - Can manage other auth keys
  - Used for HSM provisioning

Key ID 3: Automation/Signing (ROMbsr default)
  - Can use signing keys
  - Cannot create/delete keys
  - Used by sign-orchestrator

Key ID 4: Backup Operations
  - Can export wrapped backups
  - Cannot use keys directly
  - For disaster recovery

# Example: Proper key separation
$ bin/rombsr hsm-provision
Creating admin key (ID 2)...
Creating signing key (ID 3)...
Creating backup key (ID 4)...
Deleting factory default (ID 1)...
Provisioning complete!

Signing Key Architecture

# Android Signing Keys in HSM
platform    - Signs core system apps
media       - Signs media/download providers
shared      - Signs launcher/contacts
networkstack - Signs connectivity components
sdk_sandbox  - Signs sandboxed SDK runtime
bluetooth   - Signs Bluetooth system apps
testkey     - Development only (not in production)

# AVB (Android Verified Boot) Keys
avb_root    - Root of trust for verified boot
avb_intermediate - Signs individual partitions

# OTA Keys
ota_key     - Signs OTA metadata and payloads

# All keys use RSA-4096 or EC-P256 as appropriate

Cryptographic Verification Chain

End-to-End Verification

Every artifact goes through multiple layers of cryptographic verification:

1. Build Phase
   ├─ Calculate SHA-256 of unsigned artifacts
   ├─ Generate signing request with hashes
   └─ Sign request with build node GPG key

2. Queue Commit
   ├─ Verify GPG signature on commit
   ├─ Check commit author authorization
   └─ Validate request JSON schema

3. Sign Validation
   ├─ Pull request from queue
   ├─ Verify GPG signature integrity
   ├─ Validate artifact hashes
   └─ Check signing quotas/policies

4. HSM Signing
   ├─ Authenticate to HSM with role key
   ├─ Sign artifact hash (not full file)
   └─ Generate signature metadata

5. Response Validation
   ├─ Package signatures with metadata
   ├─ Sign response with sign node GPG
   └─ Commit to GitOps queue

6. Build Verification
   ├─ Verify response GPG signature
   ├─ Validate signature format
   ├─ Apply signatures to artifacts
   └─ Verify final signed artifacts
fingerprint
Hash Functions

SHA-256 for all artifact identification, SHA-512 for critical paths

vpn_key
Signature Algorithms

RSA-4096 with SHA-256 (PKCS#1 v1.5), ECDSA P-256 for AVB

lock
Key Wrapping

AES-256-CCM for HSM backup exports, never plaintext

GitOps Security Model

Why Git for Security Queue?

Immutable History

Git's merkle tree structure makes history tampering mathematically detectable. Every commit is chained to previous commits. Rewriting history changes all subsequent hashes.

Cryptographic Signatures

GPG-signed commits provide non-repudiation. Can prove who submitted each signing request. Signature verification is mandatory, not optional.

Distributed Verification

Multiple parties can maintain queue copies. Discrepancies are immediately obvious. No single point of failure or trust.

Queue Security Policies

# Git configuration for signing queue
[core]
    # Reject unsigned commits
    rejectUnsigned = true

[receive]
    # Only accept signed pushes
    certNonceSeed = <random>
    advertisePushOptions = true

[push]
    # Require GPG signatures
    gpgSign = true

# Branch protection rules
- main branch: protected
- Force pushes: disabled
- Signed commits: required
- Reviews: optional (for manual verification)

Security Best Practices

Operational Security

admin_panel_settings
Principle of Least Privilege

Build nodes cannot sign. Sign nodes cannot build. Admin access separated from operational access.

psychology
Defense in Depth

Multiple security layers: network isolation, HSM protection, audit logging, cryptographic verification.

visibility
Security Transparency

All operations logged and observable. Security through openness, not obscurity.

Deployment Security Checklist

□ Physical Security
  ✓ HSM in locked datacenter cabinet
  ✓ Access logs for physical entry
  ✓ Security cameras on HSM location

□ Network Security
  ✓ Sign nodes on isolated network segment
  ✓ Firewall rules limit HSM access
  ✓ No internet access from sign nodes

□ Access Control
  ✓ Multi-factor authentication required
  ✓ SSH key-based access only
  ✓ Audit logs for all access

□ Key Management
  ✓ HSM provisioned with unique passwords
  ✓ Factory default key deleted
  ✓ Backup keys stored in separate location

□ Monitoring
  ✓ Prometheus alerts configured
  ✓ Log aggregation enabled
  ✓ Anomaly detection active

Compliance & Standards

Industry Standards Alignment

FIPS 140-2 Level 2

YubiHSM2 hardware certification ensures cryptographic operations meet US government standards. Tamper-evident hardware with role-based authentication.

Common Criteria EAL4+

HSM evaluated for methodically designed, tested, and reviewed security. Suitable for protecting high-value assets against sophisticated attacks.

PCI DSS Compliance

Architecture supports PCI requirements for key management. Audit trails, access controls, and key rotation capabilities built-in.

Audit & Compliance Features

Incident Response

Security Incident Playbooks

Suspected Key Compromise

1. Immediately disable signing operations
   $ sudo systemctl stop rombsr-sign

2. Revoke potentially compromised keys
   $ bin/rombsr hsm-revoke --key-id <id>

3. Audit recent signing operations
   $ cd signing-queue && git log --since="2 days ago"

4. Generate new keys if needed
   $ bin/rombsr hsm-rotate-keys

5. Update all ROM builds with new keys
6. Publish security advisory

Unauthorized Signing Attempt

1. Check audit logs for anomalies
   $ journalctl -u rombsr-sign --since="1 hour ago"

2. Verify queue integrity
   $ cd signing-queue && git fsck

3. Review recent commits
   $ git log --show-signature

4. Check for unauthorized modifications
   $ git diff origin/main

5. Investigate and document findings