card_layout.txt

====================
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.