Token It Up A Notch: Elevating Payment Security

### Overview In this talk, security engineer Jovan (V) and software engineer Yudi share how Chime engineered an internal tokenization platform to reduce PCI-DSS scope while supporting expanding business needs. Historically, Chime avoided handling primary account numbers (PANs) directly. However, new business requirements—such as card onboarding, cashback rewards integrations with payment networks (Visa/Mastercard), digital card displays, and reporting to banking partners—necessitated handling sensitive payment data. The engineers designed an in-house tokenization architecture to replace raw card numbers with opaque tokens, isolating cardholder data into a dedicated, highly secured environment.

### Key Topics - **Tokenization & Envelope Encryption:** Replacing sensitive data (PANs, SSNs, ITINs) with UUID tokens while encrypting underlying card data using envelope encryption. - **Network Isolation & Authentication:** Segmenting the tokenization infrastructure within a private network accessed via AWS PrivateLink, employing Okta for human Single Sign-On (SSO) and mutual service-to-service (S2S) authentication. - **Data Schema & Association:** Isolating keys across discrete data families and leveraging HMAC digests to query and map raw values back to tokens without decrypting entire databases. - **Performance & Batch Processing:** Re-architecting file detokenization for multi-gigabyte regulatory/partner reporting from slow sequential routines down to sub-10-minute parallelized workflows. - **Threat Modeling & Insider Threats:** Designing defenses across multiple trust boundaries, including locked-down support environments, rate limiting, and anomaly detection for rogue staff.

### Technical Details - **Architecture & Infrastructure:** The system runs as a containerized Go binary within AWS Elastic Kubernetes Service (EKS) and utilizes AWS KMS, Aurora PostgreSQL, and S3. Internal services connect via AWS PrivateLink, communicating through HTTPS, Twirp (a Protobuf-based RPC framework), or Amazon SQS for asynchronous jobs. - **Envelope Encryption & Key Management:** Plaintext values are encrypted with a Data Encryption Key (DEK) via AES, while the DEK itself is encrypted under a Key Encryption Key (KEK) managed in an AWS KMS HSM. Encrypted DEKs and ciphertexts are stored in Aurora PostgreSQL; plaintext KEKs never leave KMS. DEKs are rotated after every 100 operations to balance blast radius reduction against customer onboarding latency and AES-GCM nonce limits. - **Decryption Flow:** The Go service extracts the token ID, validates the data family, fetches the encrypted DEK, decrypts the DEK using the KEK via KMS, and then decrypts the ciphertext. - **Batch Detokenization:** Processing reporting files with tens of millions of records previously took 8 to 9 hours. By sharding files, implementing caching, and executing detokenization concurrently, the job duration was reduced to under 10 minutes. - **Customer Service App & Threat Mitigations:** To handle law enforcement inquiries matching PANs to account owners, a legacy Ruby on Rails customer service app embeds the Go tokenization UI via a sandboxed iframe. Controls include locked-down Chrome browser instances, client certificates, rate limiting, short-lived JWTs with strict expiration (`exp`) and algorithm validation, just-in-time SSH access via bastion proxies, and DataDog monitoring with anomaly alerts (e.g., capping support agent lookups to 20 per hour).

### Takeaways Building an in-house tokenization system requires strict domain separation across data families, rigorous envelope encryption, and minimal service-to-service access. Key takeaways include keeping web frontends simple (using vanilla Go templates rather than complex frameworks to minimize attack surface), relying on automated dependency patching (Dependabot) and internal ECR mirror builds, and treating insider threats as first-class threat models through strict rate-limiting, investigation queues, and automated alerting.