==================== Security card layout ==================== Needs ===== Parties ------- System: All the following parties regrouped. Badger: either an access-control frontend, requiring PIN or not, or a debit/credit system. Some badgers are in a hostile zone, may be stolen, debugged, reverse engineered. This has implications on security model. Backend: Secure element that knows the keys to access cards secrets. It is considered secure against thieft or teardown. Card: MFP token carried by user. It acts as an identification/authentication/authorization token. It also acts as an electronic purse that can be debitted for various internal payment procedures. Security model -------------- MFP design is considered secure in a way it may not leak sectors keys during transmission nor with offline attacks on the card. Security model relies on shared secret between card and reader. Shared secrets should remain secret. Two set of keys exist. Keys shared between badgers and cards, and keys shared between backend and cards. Keys that are used by badger directly should be considered as public. They shall only allow read of memory. System should consider an emulator can inpersonate a card with these keys, presenting forged data. Data read by badgers directly should be validated by other means and should be protected against replays by other means. Data that cannot tolerate replay attacks must use private keys only known by backend and card, whether those keys are used for auth in MFP or encipherement of blobs. In such cases, badger acts as proxy for transactions that happen between backend and card. Such badgers must be online. Stored objects -------------- There are various things to store on the card: 1. An authentication and authorization blob. It contains identification of subject (name, dob, BM uid, etc.), its credentials (a bitfield, or a list of IDs). Credentials are valid for a limited period of time. 2. Backend-specific data. A blob encoded and used by backend. Only stored verbatim on card. Expected modification frequency is low (as low as update of 1.). 3. A Transaction serial ID. This is a block configured for decrement only. No way to increment it again. It is used as transaction nonce for 4. 4. An electronic purse amount. It may be read by the same people than 1., but may not be forged, and may not be replayed. It should probably be double-banked in order to be able to atomically update it. Depends on 3. Size requirements ----------------- 1. This should probably be a DER-encoded payload for compacity. The whole blob is signed (ed25519) with a BM key. Let's reserve 32 bytes for name and given name, 4 bytes for dob, 4 bytes for UID, 4 bytes for expiration time, 32 bytes for ACL, and 4-7 bytes for card UID. With 64 bytes of signature, we have a worst case around 168 bytes. This fits in 4 sectors (192 bytes). 2. This requires a single sector, may use more depending on signature scheme from backend. It can be merged with data from 1. Splitting could optimize passing blob back to backend on read. 3. This requires a single sector with value encoding. 4. With 64 bytes of signature, this requires at least 2 sectors. 32 bytes are left for signed data. We need at least 4 bytes for amount and 4 bytes for counter, plus 4-7 bytes for card UID. With double banking, this requires 4 sectors. Total: at least 10 sectors. This fits a MFP 2k (32 sectors). Card/reader/backend lifetime ============================ Personalization --------------- Personalization of card is the setup phase where secrets are uploaded to the card in a cleartext way. This must be done in a secure environment (i.e. not remotly). Cards can be personalized by batches, and stored personalized but blank. Credentials loading ------------------- Backend generates blobs for 1. and 2., uploads them to the card through any badger. Write transactions are done by the backend directly. Identification/Authorization ---------------------------- Badger authenticates to 1. and 2. with using A keys, it retrieves signed identification blob and backend-specific blob (if needed). Credentials are checked in badger itself. If PIN is needed, it can be asked to user and forwarded to backend with backend-specific blob. Backend tells whether it validates the PIN. Backend can implement bruteforce countermeasures (exponential backoff, Schroedinger, etc.). When a badger systematically requires a PIN, its GUI can ask for PIN before asking for card, swiping card acts as a validation for PIN entry. All transactions are read, they can be done by the badger directly. PIN validation requires backend presence. Credit/Debit ------------ Reading credit for display can be performed by bagers. Being able to read credit does not make the card authentic. Credit can be trusted only if credit/debit transaction successfully completes. Strong validation of card could involve a transaction of -0. Transactions are done by the backend directly. This must always be done through backend as the System cannot trust cards against replay attacks if write keys are known. Entity asking for debit should authenticate to backend first, then ask for transaction. Debit operations should probably send a log entry to backend first. Credit operations should be validated by backend through other means, easiest one is to have the backend maintain a list of pending credits waiting for cards, and commit them to cards afterwards. Key management ============== Key requirements ---------------- 1/2. There is no strong requirement for confidentiality of this part, except when card is read by a stranger in a public place. Threat model comes from emulation of genuine card. If this happens, only read key needs to be known in order to clone a valid token (reader is unable to verify write key after all). Forging a token is never possible (unless signature key leaks). Cloning/emulating a valid tag should be considered harmless. It has a limited lifetime, and it should be authenticated with a PIN where necessary. PIN requires backend interaction, and is a TFA. Key A: Read-only, used from badgers Key B: Read-write, used from backend Blob PuK: used from badgers (or a PKI in another sector ?) Blob PrK: used from backend 3. As knowning read key allows emulation of valid card, transaction commitment should only be done when write is successfully done. Read should be considered as informative and does not make transaction successful by itself. Key A: Read-only, used from badgers Key B: Decrement only, used from backend 4. Same as 3.: reading does not guarantee card is not emulated. Key A: Read-only, used from badgers Key B: Read-write, used from backend Blob PuK: used from badgers (or a PKI in another sector ?) Blob PrK: used from backend Keys should be diversified with card UID. Questions --------- Key B for 3. may also be in badgers, because all that can be done with it is committing a transaction that is already recorded, or brick a card. Only thing to fear is a DoS of payment system. Key B for 1./2./4. must be private. It should probably be benefical to have a TPM-like object in the backend, i.e. have shared secrets isolated in a CPU that does only transaction message crafting. This could be a Brain board physically isolated in server room, acting through the network.