Security Guarantees of SΛMSUNG Pay
SΛMSUNG Pay, once launched as independent service, is a feature of the SΛMSUNG Wallet app, which is a digital wallet that allows users to store and manage their payment cards, loyalty cards, and other digital assets. By owning the hardware and the software, Samsung is able to provide security guarantees rooted in the hardware, similar to the guarantees given by Trusted Platform Module (TPM).
Securing Phone & Merchant Exchange
How does Samsung Pay ensure the security of the payment token details exchanged between the consumer’s phone and the merchant?
The answer is: Math; specifically, public-key cryptography.
The merchant or their respective PSP (payment service provider) must first generate key pair and a CSR (certificate signing request) with the key. They, then, create a Service on the Samsung Pay Developers portal and upload the CSR generated earlier to share it with Samsung.
During a transaction, Samsung Pay server generates a short-lived TLS certificate using the CSR and signs it with Samsung private key. The signed certificate is then sent to the device to encrypt the token using the embedded public key (after validating the certificate chain, but this is done by on-device Samsung Pay facilities for you).
The encrypted token is then given to the merchant/PSP (service ID owner). The service owner is expected to decrypt the token using the private key of the CSR. Only the holder of the private key is capable of decrypting the payment credentials.
Effectively, only the device itself and the merchant/PSP receive the payment credentials, which are also of limited scope, enabling secure payments through math.
Original article on my LinkedIn profile.
Authenticating In-App Payment Requests
How does Samsung Pay know the Android app requesting payments is not spoofed?
When the in-app service profile is created on the Samsung Pay Developers portal, the developer receives a service ID which they ought to use with the Samsung Pay SDK when requesting the payment. What if the service ID falls into the hands of fraudsters or hackers?
The service ID is not a secret. It is an identifier. When creating the service profile, the developer enters the application/package ID and is instructed to upload the production APK of their app. When the merchant app interacts with the Samsung Pay SDK, Samsung Wallet app checks the caller app package ID and verifies its signature matches the signature of the APK uploaded by the developer on the portal. Therefore, a rogue app that is side-loaded on the phone cannot pass the verification checks of the Samsung Wallet. The mechanism proves to Samsung Pay the caller app has access to the Samsung Pay Developer portal, can sign APKs with the merchant’s key, and has access to the signed APK of the merchant.
Original article on my LinkedIn profile.
Authenticating Web Payment Requests
How does Samsung Pay know the website requesting payments is not spoofed? What if a rogue network admin deploys a DNS server within the network that serves a phishing site on the payment page known to host Samsung Pay payment flow?
When creating the service profile on the Samsung Pay Developers portal, the developer enters the authorized service domain names (FQDN) that will host the Samsung Pay JS SDK. When loaded, the SDK checks the page is hosted on HTTPS and that the host name is configured by the developers as an authorized domain name for Samsung Pay operations. This proves to Samsung Pay that the site developer has control over the DNS A/AAAA/CNAME records and access to the service profile.
Protip: Marketplace Providers and iFrame-d Payment Forms
PSPs who provide hosted payment form that is injected as an iframe into merchants websites may prefer to have a small set of Service IDs (e.g. one) for the hosted merchants. It would be cubersome for the merchant to handle split integration of payment processing, one where they have to interact with the Samsung Pay SDK and another where the PSP manages the form. How could the merchant offload the full payment interaction to the PSP while Samsung validates the requestor domain name? Nested iframes. The PSP creates a single Service ID with the authorized domain name being a dedicated (sub)-domain for the hosted form service. This is the domain name Samsung will see and validate as being authorized. The PSP’s responsbility then becomes to validate the website hosting its payment form, i.e. the iframe, is an authorized website per the merchant’s profile.
Go Module
To understand the implementation and to support merchants and PSPs with the utilization of the Samsung Pay SDKs, I developed a Go (golang) module that illustrates how to decrypt the payment credentials. The decryption of the JWE provided by Samsung Pay SDKs is not conventional, and the Go package is meant to show developers how to do it in a modular manner. The module also includes mocking facility that generates JWE for testing purposes.
GitHub: https://github.com/mohammed90/samsungpay-codec Godoc: https://godoc.org/github.com/mohammed90/samsungpay-codec
Section is derived from the original article on my LinkedIn profile.