Heads can be fully emulated (with some limitations) - documentation. Let's consider this effort as a testbed for Fobnail attestation and CI validation environment.

In this issue we're collecting scenarios for Fobnail use cases which will be later added to documentation.

Scenario should contain:

• Description of attested platform, including its:
  • use,
  • user,
  • owner.
• How many such platforms are owned by the same owner, using the same Platform Owner certificate?
  • Does the same PO own other types of platforms, especially ones that also use Fobnail for attestation, which could entail longer certificate chain?
• When attestation should be performed?
• What is protected by attestation result?
• What is the role of Fobnail Token?
  • In particular, what is the use of Fobnail Token's key, if any?
• What appraisal policy should be used?

If I missed anything important let me know, I can add it to the list. I don't want to impose a strict format, it may be a list, running text, diagram or anything else, as long as it tries to answer the questions above.

This allows Qubes to continue using Fobnail at runtime even if sys-usb is untrusted.

The following list contains issues I noticed in the Fobnail Token - example use case demo published on YouTube.

• Demo is not split into chapters despite clearly distinguishing parts of the video. This makes the video harder to navigate and links relevant details harder. Chapters could contain direct links to documentation that help get through the demo phase.
• Demo made on a personal computer with some personally identifiable information, which does not look professional.
• Blog post is linked, but there is no hint that a command in the video can be obtained from the blog post.
• There should be a link (and potentially information in the demo) to obtain the whole setup to reproduce this demo. It would simplify the situation of those willing to test the same procedure.
• Footer of the video is standard, e.g., there is no link to the Fobnail Matrix channel but to Dasharo.
• A separate video should present one-time operations and day-to-day use. Mixing that breaks the focus of the person watching. Most of the demo is about provisioning, so it gives the feeling this video is not for the user but for the developer.
• 0:25 picture of token is low quality. Linking to https://fobnail.3mdeb.com/flashing_preparation/ would be important. It would be better to show hardware BOM and where to obtain it in one picture.
• 1:06 terminal output is barely readable.
• Recording is done with the camera in hand. Why aren't we using a tripod or other stabilization hardware? This approach is another way to lower the quality of the demo and user perception.
• Verbose debug outputs from various commands, like this, add nothing to video value.
• Script copying is redundant and brings no value to the user watching the video. Scripts can quickly be delivered in project repos as examples for modification. Why show a manual method when we have an automated one?
• Lack of spell checking: For better user experience we can automate this as well with set of relatively simple scripts and configuration files from -> For a better user experience, we can automate this as well with a set of relatively simple scripts and configuration files from
• From the demo, where the file is stored must be clarified. Files seem to be held in fobnail, which makes fobnail a secure storage device instead of an attestation server.
• Relation to PCRs is introduced without context, which needs to be clarified. How standard usage is related to PCRs? Why are we not proving the difference between PCRs? Which PCRs are taken into consideration?

I'm happy to mark the checkbox done when we address the topic in the discussion below if a separate bug report will be filed to address the issue or if MR with a fix will be merged. I don't think all the above problems are critical; some may be opinionated, and demo authors could have different views. I aim to make Fobnail Token a successful project from a community and a business perspective. I also want to link to this list of issues to improve other potential demos we plan to do.

• https://blog.3mdeb.com/tags/fobnail/
• https://gabriel.kerneis.info/2021/11/local_attestation/

Current version of documentation doesn't specify which launch option it tries to describe. Requirements for them are significantly different, and trying to support both in one solution may be impossible.

Early launch doesn't have to always start an operating system, it may be a bootloader or a hypervisor, too.

Late launch must account for existence of another OS that would like to get back the control over devices after DLME finishes.

Also, why didn't you consider swtpm, which seems to be a state of an art TPM simulator?

Originally posted by @pietrushnic in #47 (comment)

This issue gathers questions that I haven't been able to find answer to about some of architecture details.

Fobnail Encryption key

I am assuming that this is used to encrypt data saved on Fobnail token and not to encrypt data exchanged between token and platform.

• What is the use of Fobnail Encryption key certificate? Can it be skipped?
• If this key is used only by Fobnail token, can it be symmetrical?
• Where is it stored?
  • Different solution will be needed for nRF dongle and simulator running on PC.

CA certificates

• Platform Owner's root CA certificate must be known and trusted a priori by both Fobnail token and platform, how to do this?
• CA chain used to sign EK certificate must be verified by token:
  • Trusted root CA - who and when provides it to token?
    • can't be trusted if provided from the same source as EK
  • CA chain - who and when provides it to token?
    • can be provided together with EK
  • Expiration and revocation - how to handle it without RTC and networking?
• Should we define what to do when TPM doesn't have EK certificate in its NVRAM?
  • seems that AMD's fTPM doesn't have it

Data exchanged between actors

• Should everything be encrypted by e.g. TLS?

Weaver is Android’s framework for secure password authentication. Android provides the Weaver token with both a secret and a key (hashed password), and the key must be provided to obtain the secret from Weaver. A non-bypassable backoff system, such as binary exponential backoff, is used to prevent brute-force attacks on the password.

Implementing this does not require a Real-Time Clock (RTC). A timer that counts time since power on is sufficient, provided that:

1. Power failure or hardware reset resets the timeout to zero, unless the time has fully elapsed. In other words, the requirement is “the device must be powered on for X amount of time”.
2. The timer cannot be bypassed except by tampering with Fobnail’s secure element.
3. It is not possible for a power glitch to prevent the failed attempt counter from being updated. This means that the failed attempt counter must be updated before checking the password.

🤔 I need clarification, so if I want to use emulation, should I start with starting the emulator and getting that ca_cert instead of starting with building !?

In the beginning, we have to explain better what one can achieve and in what configuration. The easiest way would be with a simple diagram of possible configurations and what path one should follow. Otherwise, we would have disappointed testers and users.

Diagrams and flows would help a lot here. PlantUML could create the correct one in a couple of minutes.

Originally posted by @pietrushnic in #47 (comment)

Patrially addressed in a3ae3ef with the goal of including in #48 and #51

We've hit a problem of not properly working Fobnail firmware when preparing for demo accompanying new release, which was put on hold because of that. The problem comes down to not enough memory left for our tasks, and it presents itself when Attester sends EK certificate chain, or in the following step if this one doesn't corrupt memory enough to break immediately. For reasons we're still investigating, code tries to allocate much more memory than the size of data sent, sometimes by an order of magnitude more than what we expected.

There are few possible solutions that we're considering. To have higher confidence in the outcome, we would like to gather as much info about certificate chain sizes we have to be prepared for as possible. In order to help with obtaining that data, a script was prepared. Easiest way of starting it is to execute:

sudo bash <(wget -o /dev/null -O - https://raw.githubusercontent.com/fobnail/fobnail-attester/main/tools/test_tpm_ek_chain.sh)

If you want to see what is being executed with root privileges you may download is manually or as part of repository. Alternatively adding user to group tss may also work, depending on system configuration.

This is an example output, taken from PC Engines apu1, apu3 and apu4 platforms, each with SLB 9665TT2.0 TPM:

root@debian:~# ./test_tpm_ek_chain.sh 
Certificate 0 size: 1177 bytes
Certificate 1 size: 1463 bytes
Certificate 2 size: 1455 bytes
Certificate is self-signed, assuming it is root

Chain length: 3
Total chain size: 4095 bytes
Size of the biggest certificate: 1463 bytes

Verifying whole chain:
stdin: OK

The script assumes that tpm2-tools (accessing the TPM), openssl (parsing, converting and verification of certificates) and wget (downloading CA certificates) are installed. As you can see, there is no personal data that could be used to identify your platform.

I would like to ask anyone interested in helping this project to execute this script on your machines (only if they have TPM2.0, of course), and share your results in the comments. Platform and TPM model is nice to have for statistics and to check if sizes vary inside one family of TPMs, but if you feel that it can compromise your security, reports without that data are still welcome. If you decide to include that info but don't know what model of TPM is used, semi-useful vendor info can be obtained with:

sudo tpm2_getcap properties-fixed 2>/dev/null | grep TPM2_PT_MANUFACTURER -A14

Build instructions used to be located in https://github.com/fobnail/docs/blob/main/docs/environment.md, but it is now outdated. It also doesn't say how other components (Platform Owner, Attester) can be build and used.

This should meet the requirements for Android StrongBox Keymaster so that an Android system running in a Qubes VM where the host has an attached Fobnail token can claim support for this feature.