I think this is where you want to look into a Hardware Security Module (HSM) or a solution like Hashicorp's Vault server. The split secret would be used to initialize either of those solutions (Vault uses split keys to unseal the server out of the box, and can even encrypt those shares to several different GPG keys when the root key is created, this way the shares are never exposed in plaintext form to anyone, not even the original admin that creates the key)
https://en.wikipedia.org/wiki/Hardware_security_module https://www.yubico.com/products/yubihsm/ https://www.vaultproject.io I don't know if any HSM's support hardware based protected GnuPG encryption or not. If you want to experiment with a Shamir Secret Sharing key split you can look at an implementation in Ruby that I have created which also has a simple command line interface for splitting and recombining secrets. https://github.com/grempe/tss-rb In any case I think you would have those trusted admins, with shares of a private key passphrase, unlock the key in memory at boot time of your application and this server would be the only one that is capable of automated decryption using that unlocked private key. They would need to repeat this process at each reboot or if the process that contains the key crashes. I am not aware of GnuPG ever supporting Shamir Secret Sharing style encryption key splitting. They may exist, I just don't know. Cheers, Glenn On Thu, Nov 10, 2016 at 11:10 AM NdK <ndk.cla...@gmail.com> wrote: > Il 10/11/2016 16:24, helices ha scritto: > > > Our company must decrypt ~100 files 7x24 in near real time. How can SSSS > > work - or any reasonable alternative - in such a production environment? > Wouldn't a smartcard solve (at least partially) the issue? > Insert it in a pinpad reader and have the PIN shared between two > administrators. Both are required at system boot to unlock the card. If > the card gets removed, no single admin can unlock it. > Sure, an admin could just use it while connected to the server to > decrypt files (or simply read stored files) but as others said there's > no way to prevent that if the attacker have physical access to the system. > > BYtE, > Diego > >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
