Payment Security & PCI

Description

A payment device is only as trustworthy as the firmware it runs. PCI requirements expect that only signed firmware can be loaded, that keys stay inside protected storage, and that the whole chain can be shown to an assessor.

For secore.ly GmbH I am designing the security architecture of an embedded Linux system on Raspberry Pi CM4/CM5, built with Buildroot and paired with the DDM885R contactless reader. The manufacturer owns the firmware trust domain: a hardware secure-boot chain from ROM through a signed EEPROM bootloader, a signed boot image and U-Boot, plus atomic A/B updates delivered as manufacturer-signed RAUC bundles. The customer owns a separate trust domain. No signing keys are shared between the two.

Customer applications arrive as signed, read-only squashfs images. The DDM885R takes part in signing them through its PKCS#11 API. Each image is verified on the device before it is attached with portablectl and run, sandboxed, under systemd-nspawn. Sandboxes use ProtectSystem=strict, NoNewPrivileges and PrivateTmp, and each application gets its own persistent writable storage through a bind mount, so a firmware update never disturbs an application update.

For DDM Hopt+Schuler I extended the MCUBoot imgtool Python sources so firmware images for the DDM885R are signed with keys held in PKCS#11 storage, rather than with key files on a build machine.

On the same project I brought up a Linux shared library with an RPC client and server that carry PKCS#11 API calls as JSON-RPC messages encoded in CBOR, using the QCBOR library. The server side was then prepared for porting to the device running NuttX RTOS.

Combined with many years of EMV and terminal development, this lets me help with the security side of a payment product: secure bootloaders, key management, cryptography with OpenSSL, and preparing the evidence needed for compliance.