Security Model & Threat Analysis
ColossusNet trust assumptions, threat model, offline transaction security, and key hierarchy.
Security Model & Threat Analysis
ColossusNet's security model combines EMV chip-level cryptographic guarantees with on-chain verification to produce a system where transaction integrity is enforced end-to-end.
Trust Assumptions
ColossusNet operates under three core trust assumptions:
| Assumption | Description |
|---|---|
| Terminal Trust | ColossusNet assumes EMVCo Level 1 (contactless interface), Level 2 (kernel), and Level 3 (application-level) certified terminals. The terminal is the trusted origin of DDOL data (amounts, unpredictable numbers, merchant/terminal IDs). The acquirer maintains a secure message channel (TLS 1.3 / mTLS) with the terminal per PCI-DSS requirements. |
| Card Secure Element | The JavaCard secure element provides tamper-resistant storage of the ECDSA P-256 private key. The key cannot be extracted, cloned, or computed from external observation per Common Criteria EAL5+ certification of the chip. |
| Acquirer Integrity | The acquirer correctly forwards ISO 8583 messages without modification, per existing card network agreements and PCI-DSS compliance. |
Threat Model
| Threat | Mitigation | Status |
|---|---|---|
| Replay Attack | Unpredictable Number uniqueness (tracked on-chain) | Implemented |
| Relay Attack | Terminal-generated Unpredictable Number binds transaction to specific terminal session. Kernel C-8 (RIX 1020) adds RRP for contactless. | Partial (C-3: timing-based, C-8: RRP) |
| Card Cloning | ECDSA private key stored in secure element; cannot be extracted. ODA failure is by design, not exploitable. | Mitigated by hardware |
| Amount Manipulation | DDOL includes amount; signed by card. On-chain validation rejects mismatched amounts. | Implemented |
| Merchant Impersonation | DDOL includes Terminal ID + Merchant ID; signed by card. AcquirerConfig validates registered merchants. | Implemented |
| Currency Manipulation | On-chain validation restricts to USD (0x0840) only | Implemented |
| Signature Forgery | P-256 ECDSA with 128-bit security level; computationally infeasible | Cryptographic guarantee |
| Nonce Reuse | Unpredictable Number generated by terminal hardware RNG per [EMV Book E] Section 8.1 | Terminal responsibility |
| Key Compromise | Per-card unique key pair. Compromise of one card does not affect others. | Architectural isolation |
| Smart Contract Bug | Target/selector binding prevents signature reuse across functions. Separation of validator and executor. | Implemented |
Offline Transaction Security
If a terminal operates offline-only (no network connectivity), the transaction MUST be declined. The following combination of safeguards ensures this:
- AIP indicating DDA: which will fail due to ECDSA (the terminal cannot perform ODA locally)
- Floor limit of 0: all transactions go online
- TAC Denial catching ODA failures: ODA failure triggers a decline
- IAC settings matching TAC: the card's issuer action codes reinforce the terminal action codes
This ensures that an offline terminal will generate an AAC (Application Authentication Cryptogram = decline), never a TC (Transaction Certificate = offline approval).
There is no offline approval path in ColossusNet. This is a fundamental security invariant.
Key Hierarchy Security
| Key | Storage | Protection |
|---|---|---|
| CAPK Private Key | HSM (issuer infrastructure) | Hardware Security Module, access-controlled |
| Issuer Private Key | HSM | Hardware Security Module |
| ICC RSA Private Key | JavaCard secure element | EAL5+ certified chip |
| ICC ECDSA Private Key | JavaCard secure element | EAL5+ certified chip |
| Card Public Key | On-chain (EMVValidator storage) | Immutable after registration |
The key hierarchy follows a layered trust model:
- CAPK (Certificate Authority Public Key) and Issuer keys are stored in Hardware Security Modules under strict access controls. These are used during card personalization to sign the card's certificates.
- ICC (Integrated Circuit Card) keys (both RSA and ECDSA) reside in the JavaCard secure element on the physical card. The EAL5+ certification guarantees that these keys cannot be extracted through physical or logical attacks.
- Card Public Key is stored on-chain in the
EMVValidatorcontract's storage. Once registered during card onboarding, it is immutable and serves as the root of trust for all transaction validation.
OFAC Compliance
ColossusNet enforces OFAC (Office of Foreign Assets Control) sanctions compliance at the sequencer level. The sequencer screens transaction participants against the OFAC sanctions list before including transactions in blocks. Sanctioned addresses are blocked from transacting on the network.
This compliance check operates independently of the EMV transaction validation. Even if a card signature and on-chain validation succeed, the sequencer will reject transactions involving sanctioned addresses.