cimnine

Commercial HSM have ways of exporting the key they hold onto smartcards. Usually the keys are split onto a number of smartcards, let's say 3. For increased robustness, each third is written to two smartcards. (We now have 6 cards.) These smartcards each belong to one person, who is the only one knowing the PIN that protects the third of the key it holds. Each of these smartcards is then brought to different bank vault, sealed in tamper-proof bags.

To restore the key, you need to bring 3 out of 6 persons to the so-called key ceremony, and each has to bring his smartcard and his PIN.

The same mechanism can be used to provision multiple HSMs with the same key material. But there are other means to do this. As soon as two HSM share a common secret, also known as Key Sharing Key, they are able to exchange all key material they possess in a secure manner.

Some HSM don't even bother to store the keys they generate within the bounds of their hardware. Only it's master key is stored in it's hardware, any other key is encrypted with the master key and stored on a shared filesystem.

If this sounds artificial to you, let me assure you that such procedures are in place at various companies who deal with raw credit card data, at least in Europe. The EMV committee, the PCI organization and each issuer of credit card do mandate such procedures.

And they are very strict. We once had to ship HSMs back to the vendor, because at some point they were not supervised by at least two persons. (At least the documentation thereof was missing.)

You can disable Google SMS 2FA anytime.

You could configure dockerd (in the VM) to listen on TCP [1][2], then, back in OpenBSD, define & export `DOCKER_HOST` [3] and from then on use the 'docker' client on OpenBSD [4] without even having to ssh into Alpine.

Warning: I have not yet tested this yet, but it's about the same way as it works on macOS.

Also, I would have probably tried to use boot2docker [5] as guest instead of Alpine.

[1] https://docs.docker.com/engine/reference/commandline/dockerd...

[2] https://docs.docker.com/engine/security/https/

[3] https://docs.docker.com/engine/reference/commandline/cli/

[4] https://www.freshports.org/sysutils/docker/ (< you probably have to build it yourself)

[5] https://github.com/boot2docker/boot2docker

But that should be 'from 1.1.1970', i.e. from the unix epoch. Still far out, though.

There's a huge Google lab in Zurich [1], probably that's why.

[1] https://careers.google.com/locations/zurich/

> You may wish to enforce hibernation and evict FileVault keys from memory instead of traditional sleep to memory:

  $ sudo pmset -a destroyfvkeyonstandby 1
  $ sudo pmset -a hibernatemode 25

> If you choose to evict FileVault keys in standby mode, you should also modify your standby and power nap settings. Otherwise, your machine may wake while in standby mode and then power off due to the absence of the FileVault key. See issue #124 for more information. These settings can be changed with:

  $ sudo pmset -a powernap 0
  $ sudo pmset -a standby 0
  $ sudo pmset -a standbydelay 0
  $ sudo pmset -a autopoweroff 0

See [1] for more macOS hardening tricks.

[1] https://github.com/drduh/macOS-Security-and-Privacy-Guide#fu...

Look at Elastic's product, i.e. Elasticsearch, Logstash, Kibana, etc. Or Oracle with MySQL and Java. Redhat's OpenStack. Spring for Java. EhCache. Even .NET from Microsoft is also starting to accept third-party work. There are a lot of such examples, and that's usually a good thing. Because it means that there is someone with a different interest, than just working on cool things, behind the product (i.e. Money) and driving it foreward. Also, having professional support offered makes it sometimes much easier when convincing stakeholders to build upon an OSS product instead of a closed source equivalent.

I could imagine this for collision avoidance in a very small UAV, e.g. a vacuuming robot.

You might find reports about just this from Switzerland. Zurich started as early as 1994 with a program, which provides clean drugs, and safe places to take them, to proven addicts.

It's been quite a success and the program is now nation-wide and backed by laws.

Just make sure the (canonical) email address is not the primary identifier for the user, as email addresses may change over time.

I had some fun with this as well a while ago. It's too bad that with IPv6 we'll only get one loopback address (i.e. ::1) and not again a whole loopback subnet.

I wonder if they got the seeds ('secret key' in [1]) for the 2FA as well.

[1] https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_A...

In Switzerland, the REGA (a rescue aircraft operator) does this for finding avalanche victims. A helicopter circles above the area, where the avalanche came to a stop. Amongst other techniques do they search for radio signals, such as those of special avalanche rescue devices and those of mobile phones.

This, and certain other capabilities, should be guarded like access to location data: Available upon user agreement only and just on secure connections (i.e. TLS).

Another cool util to test/debug HTTPS is https://testssl.sh

It especially useful in locked-up environments where the server-to-server communication must be TLS, yet both servers are not directly accessible from the 'public' internet.

I store mine on a YubiKey. I only need any NFC capable Android device and the app that Yubi provides and I'm all good.

nice 'syntax highlighting' ;)