Simplifying OEM reset/Re-ownership

[JonathonHall-Purism]

From my perspective, a key purpose of OEM reset is to offer a streamlined way to get from an unknown, unconfigured, or partially-configured state to a working state as simply as possible. Chaining together the necessary resets, signatures, configurations, etc. is complex due to the nature of Heads.

As of #1515 though this workflow has grown, it now has grown to 10x Y/N questions (depending a little on config / selections) with a few other free prompts sprinkled in. Some of these questions are fairly complex with several lines of explanation.

How can we simplify the OEM reset?

---

I don't want to alienate high-tech users of course, but I do want to offer accessible security for less technical users, which requires striking a balance.

I see OEM reset as fulfilling a few key use cases for different users:

A. "Re-ownership": For users who just bought a computer, and trust the seller, it resets the security on the device and take control
B. "Factory reset": For users who have gotten lost in configuration (upgraded / changed something / lost token / etc. and don't know what to do next), but believe the device is not compromised according to their risk assessment, it offers a clear path back to a working configuration
C. "OEM": For OEMs preparing a sold computer, it configures the computer for shipment

• this could be moved to some other tool if needed
  D. Others?

---

So some strategies I have thought of to simplify OEM reset, which could become guidelines for how new features are incorporated into OEM reset vs. configuration settings:

1. Move functionality that isn't critical out of OEM reset, to separate tools or configuration
   • For configuration, this is more flexible as an OEM reset isn't required to reconfigure/enable/disable some feature
   • For tools (like maybe LUKS container reencrypt?), it's more useful as the tool can be used outside of OEM reset
   • Moving any of these out of the OEM reset path simplifies the path for users A and B above
   • As another possibility, exporting the GPG public key can always be done from the options menu. If you know what that is and need it, it is not difficult to find. Is it helpful to force everyone to understand that question enough to answer it in OEM reset?
   • For different combinations of "USB security token" and/or "encrypted flash drive" (with GPG User Authentication: In-memory gpg keygen + keytocard and GPG key material backup enabling (plus a lot of code cleanup and UX improvements) #1515 , either or both are possible), what is the minimum that must be done in OEM reset and can't be done later? Can we prepare only one device and then offer others from the GPG menu? This would be more useful after the fact.
2. Approach remaining functionality in a goal-oriented manner
   • E.g. instead of "do you want to reencrypt LUKS" - why would a user want to do that? The goal is to ensure that someone who used the computer before can no longer decrypt the disk. Maybe we should separate "re-ownership" and "factory reset"?
   • For different combinations of "USB security token" and/or "encrypted flash drive", can we ask what peripherals the user intends to use? Instead of "do you want to copy subkeys from here to there", ask "do you have a security token", "do you want to use an encrypted flash drive" and then do whatever is necessary to make that configuration work?

[tlaurion]

#1515 (comment)

Is in a state where oem factory reset is the main usage scope, and there re-ownership can be used by answering advanced questions or choosing defaults as of now in what I think is a proper questionnaire. Also, in current state, oem can enter oem factory reset by typing 'o' early at boot as well.

I think we could create scopes for further usage in early questions when non-default mode is chosen. Or have oem-factory-reset script accept parameter for re-ownership mode to go advanced.

I will tackle down later on but wanted to update this discussion with updated state of oem per PR under final review stage.

[tlaurion]

My old dream for factory reset and early re-ownership wizard was for luks and all other secrets to be randomized.

Imagine the final image showing secrets in textual form being followed by a Qr code containing randomized secrets, permitting OEM to capture provisioned secrets with a camera for archive purpose/OEM easy provisioning and file keeping, leaving all possibilities of errors of transcribing more advanced secrets to none and easing DRK sharing with customer through secure communication channels.

This would require re-integrating my old work on initial re-ownership wizard to include diceware generated secrets and could be enabled by a config option directly from board config, or by launching the script through o early at boot or any desirable way to do this.

[tlaurion]

Also note other discussion points under https://novacustom.com/forum/d/51-heads-reownership-and-nitrokey-purchase

It is to be noted that OEM refused to merge past PR that lead to the PrivacyBeast OEM factory reset/Re-Ownership wizard which is depicted at

• OEM part : https://archive.org/details/activateoemreownership
• User Re-ownership wizard: https://archive.org/details/oemuserreownership

The OEM/Re-Ownership wizard is now standard under Heads, but could be improved some more. It's time to review the above, keep in mind business flow and user needs to agree on what it should do.

In my own opinion, OEM factory reset should randomize secrets with diceware, resulting in a Qr code aimed for OEM storage. It is to remind OEMs that the only secret that needs to be shared, ideally AFTER delivery of the product is the Disk Recovery Key passphrase (DRK), while all the other secrets will be rendered obsolete when the user runs the Re-Ownership wizard.

We should also agree on which diceware passphrase list we should use:
http://www.highprogrammer.com/alan/diceware/

From experience, I would cast my vote for the EFF short list (less user errors typing short words then longer words) to the expense of changing the recommendation for passphrase length to more words under https://osresearch.net/Configuring-Keys/#oem-factory-resetre-ownership

@JonathonHall-Purism @wessel-novacustom @daringer @jans23 @pietrushnic @miczyg1 : opinions, constraints, desires?

[pietrushnic]

It is to be noted that OEM refused to merge past PR that lead to the PrivacyBeast OEM factory reset/Re-Ownership wizard which is depicted at

Would you mind pointing to where I can learn more about OEM's refusal to merge past PR? Also, where is that PR?

[tlaurion]

@pietrushnic
#551

But it was too big to be accepted as is and some parts or it has been upstreamed. Please look at the videos to see what it was and what needs to be brought back.

Now OEM factory reset/re-ownership is a different place, but not automatized for strong secret nor unique secret generation nor for OEM to extract secrets.

The more I think about this and the more I think only the DRK should be outputted as Qr code in OEM mode (OEM doesn't even need to know the secrets provisioned... Or otjerwise:why?)

[tlaurion]

launching the script through o early at boot or any desirable way to do this.

Note that that o shortcut exists today since 504f033

[wessel-novacustom]

I think we can improve the security in general by generating a random passphrase if the user chooses disk encryption (which is mandatory for Heads). We can then communicate the passphrase via email by including it into the order confirmation, which the customer can find back in his NovaCustom.com account and in the shipping confirmation email. I think this will be more secure than setting an unsafe passphrase; the same for every order.

It is relatively easy for us to setup above and we will do so soon.

We can also create another option to setup the USB Security Device for the customer. I think we will need to make this optional as it will take time per order.

For Heads, we can also add some documentation on how to build, verify and flash the firmware internally and externally. For those who care and do not want to only rely on the (optional) anti-tamper package (or don't want that option for whatever reason), they can rely on reflashing as an extra protection layer against potential tampering during transit.

Intel Boot Guard platform fusing will help us further to protect the firmware's integrity as soon as this has been released. Dasharo is working on this for our devices.

[tlaurion]

I think we can improve the security in general by generating a random passphrase if the user chooses disk encryption (which is mandatory for Heads).

Disk encryption is not mandatory for Heads but strongly recommended so that data at rest is not accessible outside of the /boot partition which currently is required to be unencrypted.

We can then communicate the passphrase via email by including it into the order confirmation, which the customer can find back in his NovaCustom.com account and in the shipping confirmation email. I think this will be more secure than setting an unsafe passphrase; the same for every order.

This depends on how the OS is deployed. The late tendency for OEM is to specialize OS installation media to be deployed in an unattended fashion, encompassing static Disk Recovery Key passphrase into the installation media + some specialized packages they desire to be deployed by default.

Some examples (same extends to Purism and other OSes in repsoitories: debian, ubuntu etc):

• Warning of hardcoded DRK passphrase: https://github.com/Nitrokey/qubes-oem?tab=readme-ov-file#initial-luks-password
  • "12345678" hardcoded for unatttended deployement: https://github.com/Nitrokey/qubes-oem/blob/f6e7ca40c344cd4ff8389ca7b466b624c2aba826/ks_template.cfg#L4

The OEM install media in this case deploys the OS with expected partition scheme and passes the OEM expected encryption key passphrase/password (DRK passphrase) of : "12345678".

---

Reminder of secrets involved under Heads (TPM, USB Security dongle, Disk Recovery Key (DRK) and TPM unsealed Disk Unlock Key (DUK): https://osresearch.net/Configuring-Keys/#oem-factory-resetre-ownership

Let's take a step back for this deployment (as opposed to cloned disks that could be deployed with clonezilla in BT mode where UUID, crypttab and DRK would be hardcoded but OS deployment is the same as OEM desired and was PrivacyBeast deployment):

• Different for all deployments: UUID of partition, crypttab, encryption key (good: unique deployement. meh: not official media based deployment. Better: salt recipes deployed reproducibly and resulting disk image auditable/downloadable.
  • Another discussion to be resumed here on how to do this better.
• Same for all deployments: encryption key passphrase (meh: DRK passphrase = 12345678, PleaseChangeMe, etc...)
• Then actual Heads OEM Factory Reset: not accepting defaults takes way too long to be OEM usable and sets default settings everywhere.

If the OEM launches the OEM Factory reset today:

• If they choose to use the defaults (first prompt) then
  • No DRK reencryption (ok: DRK is unique)
  • No DRK passphrase change (meh: DRK passphrase is 12345678)
  • USB Security dongle is resetted + provisioned with default passphrases (meh: GPG ADMIN: 12345678, GPG USER: 123456)
    • Private key generated in smartcard; never leaves USB Security dongle (good: transitioning keypairs, meh: nk3 detected forces p256 curve since RSA3072/RSA4096 were not supported nor generated in secure element back then)
    • Public key is injected into CBFS and measured as part of TPM sealed secret for firmware integrity attestation (good: unique firmware fingerprint)
      • TPMTOTP gnerates Qr code that should be kept by OEM to share as part of PoW (good: unique)
      • Same TPMTOTP secret is reversed HOTP to the USB Security dongle through GPG ADMIN PIN (meh: protected with ADMIN 12345678 which is known)

What i'm proposing here as improvements to OEM Factory Reset so OEM could better use it

• OEM hardcoding, by re-branding customization of Heads, of the initial DRK passphrase (12345678)
  • If we consider that DRK is unique, UUID are unique, crypttab is unique but DRK passphrase is hardcoded
    • OEM Factory reset could test DRK passphrase against branded one
    • If disk unlocked successfully:
      • Randomize (unattended) DRK passphrase, DUK passphrase, TPM ownership passphrase, GPG Admin PIN, GPG User PIN
      • OEM Factory Reset would provision all security components with transitional secrets
      • OEM Factory Reset COULD output only two relevant secrets to be shared to the end user:
        • TPMTOTP Qr code (the seed needed for the user to have TOTP generated on boot to be remote attested from phone/second computer)
        • DRK passphrase needed when he launches the re-ownership wizard on his own to re-own all security components; letting him choose if he wants to reencrypt and change DUK passphrase (Important note here: the whole reason Heads proposes drive reencryption is because otherwise, OEM could land DRK to authorities and end user could have his disk decrypted with old DRK passphrase if the LUKS heder is backuped and restored. This is why OEM gets in the way of user privacy otherwise is an OEM liability)

Opened a discussion under KeepassDX (unfructuous yet): Kunzisoft/KeePassDX#1443 (comment)

• Could be reduced to DRK + TPMTOTP Qr code secret and that's it

It is relatively easy for us to setup above and we will do so soon.

We can also create another option to setup the USB Security Device for the customer. I think we will need to make this optional as it will take time per order.

The problem with that here again is OEM liability.
Nitrokey proposes to his customers to provision USB Security dongle with desired Name and PINs; but the OEM should never have to know those. The Re-Ownership wizard should take care of this and does already.

For Heads, we can also add some documentation on how to build, verify and flash the firmware internally and externally. For those who care and do not want to only rely on the (optional) anti-tamper package (or don't want that option for whatever reason), they can rely on reflashing as an extra protection layer against potential tampering during transit.

Intel Boot Guard platform fusing will help us further to protect the firmware's integrity as soon as this has been released. Dasharo is working on this for our devices.

[wessel-novacustom]

It would be nice if we could have TOTP (+ HOTP) verification possible without OS by going through the OEM Factory Reset / Re-Ownership options. It would allow us to have solid root-of-trust from us (OEM) to the end user, even if no OS was chosen. A lot of users order Heads without OS.

From our side, credentials are then separately delivered via different channels (physical paper, email and Signal). Ideally, credentials should be randomly generated.

[UndeadDevel]

Just to add some user perspective on this:

1. I like this discussion and agree that OEM factory reset should be simplified; there are too many questions and the proposed solution of separating it from Re-Ownership as well as moving individual functions out to their own dedicated tools makes sense (but of course would need to be well reflected in the docs of the OEM so the user knows which functions to trigger after getting the product).
2. I also like the proposal to use randomized secrets instead of the default "PleaseChangeMe", "123456" etc.. This actually bewildered me quite a bit when I bought my NV41, as it seems easy enough to implement (just send secrets via e-mail; could even ask if user wants to generate a PGP key ahead of time so the secrets could be encrypted...could ask this in the order form).
3. Another issue is the disparity between OEM-side requirements and user requirements; see UX issues during OEM factory reset PIN / Password questionnaire #1645, which is about me recently getting tripped up by the strange default for setting distinct passwords / PINs in the OEM factory reset questionnaire. IMHO there should be a separation of tools here; e.g., since the "press 'o' during early boot" functionality is implemented, it could be used to launch an "OEM-version" of OEM factory reset, while when launching the OEM factory reset from whiptail it would launch a "user version"; see my comment there for some more elaboration.

[tlaurion]

As of now, without going too deep in the details, the oem provisions with either default PINs or custom ones, where the current codebase takes decisions based on hotp_verification output for PIN retry counts (wrong as of writing), public signature age to decide if HOTP can be sealed with the default PIN. This bug was filed under Nitrokey/nitrokey-hotp-verification#30

Then based on age of public key (<1 month), the user is reminded to change those pins on first use. That should fit the general OEM use case (reduce costs) and lead to users doing proper decisions based on their use case and threat model.

If hotp_verification was providing non-bogus output, the oem use case up to user first use and re-ownership would be encouraged to do exactly what you talk about, being well aware to not select provisioning of the usb security dongle with default PINs. And to not accept the defaults.

Let's not forget that most users are thought to not be developpers or code signers as of now, and provisioning default PINs is not a security concern if devices are shipped seperately. If custom PINs are defined, then current codebase of Heads won't warn the user to change their PINs. It depends if OEM wants to provision secrets to ship the devices together and if the burden of sharing secrets is desired. The goal of the discussion is to define the proper way that fits both oem /user cases, define requirements and then start to work on it.

Originally posted by @tlaurion in #1645 (comment)