Mboot-shamir-ssh-unseal (enhancment) project

Communities Blog
,
1

I am taking the #devember2020 #code challenge as a good excuse to sit down and improve what my brain already had in plan, writing down here the project status and progressions as well as answering questions on any level.

The mboot project is something that came from the idea of allowing a system to have partial trust of X in close proximity (network wise) clients. Using Y of those X clients as storage for the unseal key of the core system.

Using something similar to dropbear ssh shell, but not having to store the full key on any client but split them, which is possible via the shamir’s secret sharing algorithm.

What is already in place:

  • boot hook script allowing configure to fetch passphrase or arbitrary script
  • code for generating the split key/script for clients
  • example code for setting up simple clients
  • documentation setup
  • live machine locally (media player server) + old local testing vms using this setup

Implementation plans:

  • improve the client to allow
    • using gotify/pushover/other notification service on clients
      DONE: implemented via single line of script call inside the ssh authorized line prior to unlock, using LWP perl like in the pushover example.
    • have MFA (currently only ssh key of server is used, plan is to have another device eg. public web server or android device to provide a signed OKAY message that tells the client to allow sending the key segment
  • improve documentation around threat model and mitigations
    • eg. add gpg support on server side to only execute trusted code if Y clients are compromised (bi-directional trust)
  • improve server part to:
    • use proper log_msg functions
    • retry for a certain period of time
  • general items
    • support Arch/Manjaro
    • Add a (eg. terraform based) testing suite for changes
5 Likes
2

WhTs the final status on this project? Looks neat

3

Most coding was around pushover perl code thats also kind of partially work related, might be published in the git repo at some point (thats the small Edit above from adding the DONE note).
Script is deployed via ansible, allowing host, client and type specific notification messages that do not leak a lot of metadata to the used system (here pushover), allow using multiple API keys, key rotation and “limit reached” alerting line + added calling said script from within the ssh authorized_keys command call.

As a pushover alternative (self hosting), some time was invested into checking out go and npm building pipeline (the rabbit hole is deep) and finding out how well suited a FreeBSD VPS jail would be for building + running Gotify
It does work with eg. using set PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true for npm install [email protected] :confused: aand all the pain that would come with it updating and operating it, so a no-go for right now for me (even though its inside wg encapsulated internal-only networking zone).

Android side of things did reach the PoC phase of having tested most single items on the list of the final implementation requirements, but not the overall bundling together.

I did get to talk with a friend about threat models and a use case how he can apply a similar setup for his disk decryption (after finishing boot, on Arch, still loving aur package prozess and the way of Arch).
No additions to the threat-model documentation part or adding Arch support to the actual mboot script though.

1 Like