RFC: Fobnail architecture change
arturkow2000 opened this issue · comments
Summary
Change Fobnail architecture - instead of having server on the attester and
client on Fobnail Token, server would be located on Fobnail Token and client on
Attester.
Motivation
The current architecture severely limits Fobnail Token configuration abilities
due to Fobnail Token being a client. Fobnail Token has hardcoded paths for
performing provisioning and attestation. We are not capable of sending requests
to Fobnail Token which severely limits the amount configuration possible, e.g.
an once provisioned platform can not be unprovisioned without resetting Fobnail
Token into factory state. Fobnail Token configuration cannot be changed without
resetting and going once again through the provisioning process.
It is also not possible to expose any services from Fobnail Token to Attester,
such as access to symmetric cryptographic keys or performing cryptographic
operations on behalf of attester in case of asymmetric cryptography. This is a
must for features like disk encryption or Fobnail-based authentication to
services, like VPN.
Switching to a server based Fobnail Token allows to expose services for
accessing cryptographic keys and performing administrative tasks.
Architecture change proposal
Fobnail Token provisioning
Currently, if in unprovisioned state, Fobnail Token initiates provisioning by
requesting PO certificate chain from Platform Owner, then it verifies PO
certificate chain against a trusted certificate embedded into Fobnail firmware.
If verification passes, Fobnail generates Identity/Encryption keypair and
requests PO to generate certificate from this key. Retrieval of valid
Identity/Encryption certificate finalizes provisioning process.
Instead we propose the following protocol:
- Unprovisioned Fobnail token awaits for server to commence provisioning by
sending it's certificate chain. - Fobnail verifies certificate chain against trusted certificate embedded into
its firmware. If verification is succesful, Fobnail generates
Identity/Encryption keypair and responds with Certificate Signing Request.
Otherwise an error is returned. - Platform Owner responds with certificate.
- Fobnail Token verifies and saves certificate to its internal memory. It sends
status to Platform Owner. - At this point Platform Owner configures Fobnail, like default appraisal
policy. This step is optional, if skipped, defaults will be used. - When configuration is complete, Platform Owner requests Fobnail Token to lock
its configuration. - Fobnail Token locks configuration which finalizes provisioning process. Token
can be unlocked only by reset, which wipes out all configuration, provisioned
platforms and all keys.
Local platform provisioning
Platform provisioning doesn't change much, except that the process is initiated
by platform instead of Fobnail Token. In order to protect against platform
re-provisioning itself, Fobnail Token must require user consent to provision
platform, presumably by pressing button for a few seconds. As an additional
security measure, platform provisioning could be lockable through Fobnail Token
APIs.
Previously all requests were sent in a specific order, but since Fobnail Token
will be a server now, and client is free to send requests in any order, the
server must handle this case. We want to reduce the amount of global state we
keep, all API should take as parameter everything that is required to complete
operation. To achieve this we introduce objects IDs, Fobnail Token may cache
some objects in memory, like EK or AIK. Client may use object IDs to reference
these objects. Each object is temporary and is kept at most as long as client is
connected to the server. Server regularly issues CoAP ping requests to check
client connectivity.
- Platform starts provisioning by sending it's EK certificate chain.
- Fobnail Token verifies certificate chain and sends EK object ID in response.
- Platform generates and sends AIK together with EK object ID.
- Fobnail Token responds with AIK challenge and AIK object ID.
- Platform performs Credential Activation using the provided challenge and
sends results to Fobnail Token together with EK object ID and AIK object ID. - Fobnail verifies results of Credential Activation and sends status to
the Platform. AIK is marked as trusted at this point. Fobnail Token creates
Provisioning Context and sends its ID (PC ID) to Platform. - Platform signs and sends its metadata to Fobnail, together with PC ID,
Fobnail Token verifies metadata signature against AIK bound to specified
Provisioning Context. - Fobnail Token verifies metadata and returns status. Metadata is bound to the
specified Provisioning Context. - Platform sends RIMs.
- Fobnail verifies RIMs and returns status. RIMs are bound to the Provisioning
Context. - At this point additional calls may be issued to send more data. This feature
is left for future provisioning extensions. - Platform finalizes provisioning by sending special request.
- Fobnail verifies all data bound to the Provisioning Context (AIK and RIMs
currently) saves it to flash and sends final status. - Platform is provisioned now.
Remote platform provisioning
TBD
Platform attestation
Since Fobnail Token is a server, attestation must be requested by the platform.
After plugging Fobnail Token into USB, attestation must start and complete
within a defined amount of time, otherwise platform will be considered
untrustworthy.
- Platform starts attestation by sending signed metadata to Fobnail Token.
- Fobnail token verifies metadata and returns Attestation Context ID together
with PCR selection and nonce. - Platform does TPM quote with its AIK, Fobnail Token provided PCR selection
and nonce. Result sent to Fobnail Token, to appropriate Attestation Context. - Fobnail Token performs Evidence Appraisal and returns trust decision to the
Platform. - Fobnail Token unlocks access to keys stored in flash.
Wrong repo, sorry for that, closing.