diff --git a/software/doc/card_layout.txt b/software/doc/card_layout.txt new file mode 100644 index 0000000000000000000000000000000000000000..1d1d604bdfbb7167cd97baab4b71189e0da39e50 --- /dev/null +++ b/software/doc/card_layout.txt @@ -0,0 +1,204 @@ +==================== +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.