PCI DSS compliance

[Glenn Rempe]

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.clanbo at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161110/559121c6/attachment-0001.html>