next_steps_nitrokey.md: extracted steps for Nitrokey integration #61
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,38 @@ | ||||||
| # Propose and document new API design based on CTAPHID | ||||||
|
|
||||||
| With CTAPHID used instead of CoAP, human-readable names of endpoints should be | ||||||
| changed to numeric IDs. CoAP status reporting also has to be modified to account | ||||||
| for different interface. | ||||||
|
|
||||||
| # Implement functions specific to Fobnail in libnitrokey | ||||||
|
|
||||||
| This is temporary solution to allow testing until full Fobnail support is added | ||||||
| to libnitrokey. | ||||||
|
There was a problem hiding this comment. Testing aspect is always quite important in these applications. We could at least mention that the library will be covered with unit test to ensure the proper implementation of the documented API. |
||||||
|
|
||||||
| # Rewrite Attester application to be compatible with Fobnail Token changes | ||||||
|
|
||||||
| This task consists of supporting new communication interface. All uses of CoAP | ||||||
| will be removed, and API provided by libnitrokey will be used instead. | ||||||
|
|
||||||
| # Change the way metadata is obtained | ||||||
|
|
||||||
| Currently, metadata is created from SMBIOS tables and MAC address of primary | ||||||
| network controller, as described [here](https://fobnail.3mdeb.com/fobnail-api/#adminprovisionidmeta). | ||||||
| Accessing SMBIOS requires root privileges, and reliably determining proper | ||||||
| network interface proved to be difficult, especially with USB network adapters | ||||||
| or systems with no network drivers like Heads. A new way of obtaining metadata | ||||||
macpijan marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| is required, preferably one that can easily be ported between various operating | ||||||
| systems. | ||||||
|
|
||||||
| # Port Attester application to Windows | ||||||
|
|
||||||
| Apart from metadata mentioned earlier, accesses to TPM and HID interface also | ||||||
| are done in a way specific to operating system. On top of that, building | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| applications for Windows requires different different tools and procedures, | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| which also will be done in this task. | ||||||
|
|
||||||
| ## Update documentation | ||||||
|
|
||||||
| Top level description wasn't changed since first PoC. Project evolved | ||||||
| significantly since then, and information located there no longer reflects | ||||||
| current state of the project. | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krystian-hebel I'm not sure if I fully get it.
How is
Implement functions specific to Fobnail in libnitrokeydifferent fromadding Fobnail support to libnitrokey?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libnitrokey is used for older Nitrokey models. For latest Nitrokey 3--which we are aiming here--we use pynitrokey instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably @krystian-hebel was looking for a C library to have something without Python.
Is
pynitrokeypure Python? If we are considering heads, we may have quite limited flash space to include Python interpeter and some Python modules, depending on the specific device.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Python is not suitable in this case, I suggest to write a new core library in Rust. This is something we were considering anyways but didn't had a need to yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heads has been looking at including Python: linuxboot/heads#689
But it is not there yet, and may be difficult to fit in some platforms/configs AFAIK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are confident that Rust will result in total smaller footprint than Python, then it might be a way to go.
I saw you have made some Rust work in heads already linuxboot/heads#1354 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for Python, Heads seems to also be headed in that direction. While I'm just a little worried about space issue for the interpreter itself, its modules tend to be bigger that C counterparts. I also prefer to get errors during compilation instead of runtime, especially for something that requires reflashing, but I can live with that.
Heads can increase amount of space available by using maximized builds, however this may prevent us from using DRTM later, because TXT probably requires ME to be functional.
I tried to build current CPython locally, and after disabling all optional features listed by
./configure --helpand enabling optimizations I ended up with over 130 MiB to be installed, which after default XZ compression got down to 23MiB, which is still way too much. Note that this was with default gcc/libc on my host instead of musl used by Heads, but I don't expect it to miraculously get 10x smaller.Sorry, pushed wrong version, it was described better but I forgot to save the file. Based on the above discussion I'll try to rewrite this part in a way that doesn't makes any choice definitive.