diff --git a/public/img/blog/2025-12-31/card.png b/public/img/blog/2025-12-31/card.png new file mode 100644 index 0000000..2a91454 Binary files /dev/null and b/public/img/blog/2025-12-31/card.png differ diff --git a/public/img/blog/2025-12-31/onboarding.png b/public/img/blog/2025-12-31/onboarding.png new file mode 100644 index 0000000..02b54a2 Binary files /dev/null and b/public/img/blog/2025-12-31/onboarding.png differ diff --git a/public/img/blog/2025-12-31/rotation.png b/public/img/blog/2025-12-31/rotation.png new file mode 100644 index 0000000..34ea5ae Binary files /dev/null and b/public/img/blog/2025-12-31/rotation.png differ diff --git a/src/content/blog/2024-12-31-rafiki-card-integration.mdx b/src/content/blog/2024-12-31-rafiki-card-integration.mdx new file mode 100644 index 0000000..4c1f74c --- /dev/null +++ b/src/content/blog/2024-12-31-rafiki-card-integration.mdx @@ -0,0 +1,316 @@ +--- +title: 'From Tap to Packet: Exploring Card Payments on Interledger' +description: 'A Journey from POS Onboarding to Transaction Processing.' +date: 2025-12-31 +slug: rafiki-card-integration +authors: + - Jason Bruwer +author_urls: + - https://github.com/koekiebox + - https://www.linkedin.com/in/jason-bruwer-8110766/ +tags: + - Interledger Protocol + - Card Payments + - Rafiki + - Updates +--- + +Card payments are the backbone of global commerce-trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model (standard EMV flow/state machine for an ICC/contactless transaction)? + +![ILF + Cards](/developers/img/blog/2025-12-31/card.png) + +[Rafiki](https://rafiki.dev/) is an open-source platform that enables Account Servicing Entities (ASEs) like banks and digital wallet providers to integrate [Interledger Protocol](/developers/get-started) (ILP) functionality into their systems. + +## Table of Contents + +1. [Card Payments Using Rafiki and ILP](#card-payments-using-rafiki-and-ilp) +2. [Exploring a Path from EMV Cards to Interledger](#exploring-a-path-from-emv-cards-to-interledger) +3. [Starting Point: Should you build a Kernel](#starting-point-should-you-build-a-kernel) +4. ['Hello World' for POS (Point of Sale): How Does a POS device become "Known"?](#hello-world-for-pos-point-of-sale-how-does-a-pos-device-become-known) +5. [The Transaction Moment](#the-transaction-moment) +6. [Conclusion, Where This Leaves Us](#conclusion-where-this-leaves-us) +7. [References](#references) +8. [Glossary of Terms](#glossary-of-terms) + +## Card Payments Using Rafiki and ILP + +At a high level, an ILP card transaction involves: + +1. Card (ICC) - EMV-compliant card with an ILP-linked wallet address +2. POS Device - EMV kernel + ILP extensions +3. Merchant ASE - Runs Rafiki and manages POS trust (RKI, IPEK lifecycle, compliance) +4. Customer ASE - Runs Rafiki and manages the cardholder account +5. Interledger Network - Routes value between ASEs + +## Exploring a Path from EMV Cards to Interledger + +Card payments are everywhere. They are trusted, heavily regulated, and backed by decades of operational experience. At the same time, they are often locked into closed networks and bespoke integrations. + +What we have been exploring is a simple question: +_What if card payments could naturally flow into Interledger without breaking EMV_, without replacing kernels, and without weakening the security model everyone already relies on? +This post is a walkthrough of that exploration - not a final specification, but a journey through the design decisions, trade-offs, and the emerging shape of an ILP-enabled card flow built around Rafiki, existing EMV kernels, and a small set of new supporting services. + +## Starting Point: Should you build a Kernel? + +One of the earliest and most important decisions came out of conversations with our first POS (Point of Sale) manufacturing partner, who provides both the EMV kernel and a significant portion of the overall payment software stack running on the device. +Because ILF's first objective is to enable SoftPOS, we needed to choose between two approaches: + +- developing a completely new EMV kernel based on the latest EMVCo C8 specifications, +- or leveraging the existing certified kernel already embedded in the payment stack (C2). + +After evaluating the options, it became clear that reusing the existing kernel was the most practical and lowest-risk path to delivering SoftPOS quickly and reliably. + +#### The C8 certification path would have meant + +- Brand new certification cycles +- Repeated scheme testing (Visa/Mastercard/etc.) +- Long iteration loops with labs +- Reviewing of the hardware and software stack + +#### The C2 path means + +- Existing correct EMV processing +- Secure PIN entry / PAN handling out-of-the box +- Already scheme compliant + +Exploring was very clear: + +- Use the C2 kernel +- Stay as close as possible to EMVCo documentation +- Avoid clever reinterpretations of kernel behavior + +C2, while perhaps less feature-rich than newer kernels, is predictable, explicit, and specification-aligned. That predictability turned out to be far more valuable than flexibility. + +The immediate consequence of this choice was important: ILF does not need to develop an EMV kernel. + +Instead of re-implementing deeply complex, certification-heavy logic, we could focus on: + +- APIs +- Cryptographic boundaries +- ILP and Open Payments integration +- Device onboarding +- Merchant management +- Remote key injection (RKI) and key rotation + +That framing shaped everything that followed. + +## 'Hello World' for POS (Point of Sale): How Does a POS device become "Known"? + +Before a POS can send payments into Interledger, it needs an identity. Not only a "vague" merchant identity, but a cryptographically verifiable device identity. +This led us to the first building block: POS onboarding. + +### POS Onboarding as a Trust Ceremony + +Rather than treating onboarding as a provisioning script, we started thinking of it as a ceremony: + +- The POS proves who it is (serial number, model) +- The ASE decides whether to trust it +- Cryptographic material is issued with clear ownership + +#### Onboarding + +The rough onboarding flow regarding keys looks like this: + +1. The POS generates a key pair locally and sends a CSR, along with device metadata, to the ASE +2. The ASE signs the CSR via its CA +3. The ASE generates the IPEK (Initial PIN Encryption Key) for SRED/PIN (Secure Reading and Exchange of Data / Personal Identification Number) +4. The ASE updates the terminal information to its database +5. The ASE returns the signed certificate and IPEKs (TR-34) to the POS +6. All keys are returned securely to the POS for storage + +![ILP Cards, POS Key Onboarding](/developers/img/blog/2025-12-31/onboarding.png) + +##### From this point on: + +- The POS can authenticate itself +- The ASE can verify which device is speaking +- Every future request can be cryptographically tied back to onboarding + +This turned out to be a crucial foundation, not just for transactions, but for everything else. + +### Then Reality Kicks In: Keys Don't Live Forever + +Once we started thinking seriously about certification (for example, MPOC), a practical requirement surfaced very quickly: _Encryption keys must be rotated regularly (at least monthly)!_ This is where things get interesting. + +The POS is already running: + +- POS Manufacturer bespoke software (Android / Symbian / iOS / Windows Phone) +- POS kernel +- POS WhiteBox secure storage + +And the POS Manufacturer already has strong opinions (for good reasons) about: + +- Where transaction keys live +- How PIN and PAN encryption happens +- What software is allowed to see those keys + +So rather than fighting that model, we leaned into it. A Crucial Piece Emerges: _Remote Key Injection (RKI) and Key Rotation!_ Instead of pushing key management into the kernel or POS logic, we introduced a new ASE-side service whose sole responsibility is key lifecycle management. +Not payment processing. Not EMV logic. Just keys. + +#### Key Rotation as a First-Class Flow + +The key rotation (IPEK) flow looks like this: + +1. The POS requests a new set of IPEK keys from the ASE (via the POS API) +2. The POS is cryptographically verified to ensure the request can be trusted +3. A new IPEK is generated and stored at the ASE +4. The new keys are securely returned to the POS (TR-34) +5. The POS replaces the old keys in its secure storage with the new ones + +![ILP Cards, POS Key Rotation](/developers/img/blog/2025-12-31/rotation.png) + +##### In this model: + +- The POS periodically asks the ASE for a new key +- The request is authenticated using the POS identity established during onboarding +- The ASE derives a new IPEK inside an HSM +- The key is wrapped (TR-34) and sent back +- POS Manufacturer stores it inside the POS secure WhiteBox + +A subtle but important decision here: + +- POS TMK (Terminal Master Key) is generated and injected during POS manufacturing +- Transaction keys live inside the WhiteBox +- Network / ILP keys live outside the POS SDK, in the device keystore + +This clean separation keeps: + +- Payment cryptography in the kernels domain +- ILP signing firmly under ASE control + +At this point, the architecture started to feel "right". + +## Cards Enter the Picture + +With POS EMV kernel, onboarding and key rotation in place, cards themselves become almost... boring. And that is a good thing! + +Card personalization follows standard EMV practice: + +- Card keys are generated by the issuer (Customer ASE) +- A wallet address is bound to the card +- The private key lives securely on the chip + +From an ILP perspective, the card is simply: + +- A secure signing device +- A holder of a wallet address +- A producer of cryptographic proof during transactions + +No special casing. No new assumptions. + +## The Transaction Moment + +When a card is presented, everything up to this point has been preparation. + +Now the familiar EMV flow kicks in: + +``` +SELECT AID +GET PROCESSING OPTIONS +READ RECORD +GENERATE AC +Optional PIN verification (Online) +``` + +All sensitive operations happen: + +- Inside the kernel +- Using session keys derived from the current IPEK +- With data protected by the WhiteBox + +NB: Nothing ILP-specific leaks into this phase, by design. + +### Crossing the Boundary: From EMV to ILP + +Once the kernel has done its job, the POS shifts context. Now it is no longer "doing EMV", it is requesting a payment. +This is where the ILP terminal key issued during onboarding finally comes into play. + +The POS: + +- Assembles transaction data +- References the card's wallet address (Customer ASE) +- Signs the request with its ILP key (Merchant ASE) +- Sends it to the Customer and Merchant ASE + +Importantly, we don't have the POS talk to Rafiki directly to authorize the transaction. Instead, we route everything through an ASE POS API: + +Why? + +- Authentication +- Policy enforcement +- Request normalization +- Future flexibility +- Certifications +- Key management + +The ASE remains firmly in control. Rafiki Does What It Already Does Well. From here on, Rafiki is on familiar ground. + +It: + +- Creates incoming and outgoing payments +- Applies Open Payments semantics +- Tracks lifecycle state +- Emits events + The POS eventually gets a simple answer: `Approved`, `Declined` or `Failed`. + +All the complexity stays on the backend, where it belongs. + +### What We Learned Along the Way + +A few themes kept repeating during this exploration: + +- Do not fight EMV, work with it +- Do not overload the kernel, extend around it +- Keys define trust boundaries more than APIs do +- Small, focused services are easier to reason about than monoliths +- Interledger fits best when it is complementary, not dominant + +## Conclusion, Where This Leaves Us + +What is emerging is not a replacement for card payments, but an extension of them. + +- Cards remain cards. +- Kernels remain kernels. +- ASEs remain accountable entities. + +Interledger simply becomes the connective tissue that lets value move beyond traditional rails, securely, incrementally, and without forcing the ecosystem to start over. + +## References + +- _ADPU:_ https://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit +- _EMV C2 Specification:_ https://www.emvco.com/specifications/?search_bar_keywords=c-2 +- _EMV C8 Specification:_ https://www.emvco.com/specifications/?search_bar_keywords=c-8 +- _EMV C8 Specification:_ https://www.emvco.com/specifications/?search_bar_keywords=c-8 + +## Glossary of Terms + +| Term | Description | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `AC` | Application Cryptogram (generated during EMV processing, e.g., via "GENERATE AC") | +| `ADPU / APDU` | Application Protocol Data Unit (smart card command/response format; commonly spelled APDU) | +| `AID` | Application Identifier (identifies an EMV application on a card; used in "SELECT AID") | +| `API` | Application Programming Interface | +| `ASE` | Account Servicing Entity (e.g., a bank or wallet provider running/operating accounts and services) | +| `CA` | Certificate Authority (signs certificates/CSRs) | +| `CI` | Continuous Integration (automated build/test pipeline) | +| `CSR` | Certificate Signing Request | +| `C2 / C8` | EMVCo kernel/specification “level” referenced in the article (e.g., choosing an existing certified kernel vs. a newer certification path). These refer specifically to EMV Contactless Kernel specifications. | +| `EMV` | Card payment standard originally from Europay, Mastercard, Visa | +| `EMVCo` | The organization that maintains and publishes EMV specifications (EMV Cooperation) | +| `HMAC` | Hash-based Message Authentication Code | +| `HSM` | Hardware Security Module (secure key generation/storage/crypto operations) | +| `ICC` | Integrated Circuit Card (chip card; in EMV contexts, the card itself) | +| `ILP` | Interledger Protocol | +| `IPEK` | Initial PIN Encryption Key | +| `JSON` | JavaScript Object Notation | +| `MPOC` | Mobile Payments on COTS (COTS = Commercial Off-The-Shelf; a payments/security certification context) | +| `PAN` | Primary Account Number (card number) | +| `PIN` | Personal Identification Number | +| `POS` | Point of Sale | +| `RKI` | Remote Key Injection | +| `SDK` | Software Development Kit | +| `SoftPOS` | Software Point of Sale (POS implemented primarily in software) | +| `SRED` | Secure Reading and Exchange of Data | +| `TMK` | Terminal Master Key | +| `TR-34` | ANSI TR-34 key exchange / key block standard used for secure key distribution (often referenced in payments key injection) | +| `URL` | Uniform Resource Locator |