Re: PCI DSS compliance
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 wrote: > Il 10/11/2016 16:24, helices ha scritto: > > > Our company must decrypt ~100 files 7x24 in near real time. How can > > 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
Re: PCI DSS compliance
Il 10/11/2016 16:24, helices ha scritto: > Our company must decrypt ~100 files 7x24 in near real time. How can > 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
Re: PCI DSS compliance
O, yes! I forgot about that:-( I understand as far as this goes. Our company must decrypt ~100 files 7x24 in near real time. How can work - or any reasonable alternative - in such a production environment? ~ Mike On Thu, Nov 10, 2016 at 9:07 AM, Kristian Fiskerstrand < kristian.fiskerstr...@sumptuouscapital.com> wrote: > On 11/10/2016 03:50 PM, helices wrote: > > So would I! > > > > At this point, our company must achieve PCI DSS compliance before year > end, > > and the road to that necessity leads through this auditor, who insists > that > > PGP satisfies all requirements. > > > > There is no explanation that he shares with us. > > I'd expect it being reference to shamir secret sharing scheme that I > believe formed part of PGP at some point, but haven't really looked into > PGP for a while. This would allow e.g split key in 5 parts and require 2 > or 3 at the same time to access it. For the automated system, presumably > would require two administrators to set it up, and expectation that > nobody willfully modify the application or read the full private key in > memory for the regular operation, but at that point would hinder any one > admin to have access to the full key to use outside of the system. > > -- > > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com > Twitter: @krifisk > > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > > Aut disce aut discede > Either learn or leave > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PCI DSS compliance
On 11/10/2016 03:50 PM, helices wrote: > So would I! > > At this point, our company must achieve PCI DSS compliance before year end, > and the road to that necessity leads through this auditor, who insists that > PGP satisfies all requirements. > > There is no explanation that he shares with us. I'd expect it being reference to shamir secret sharing scheme that I believe formed part of PGP at some point, but haven't really looked into PGP for a while. This would allow e.g split key in 5 parts and require 2 or 3 at the same time to access it. For the automated system, presumably would require two administrators to set it up, and expectation that nobody willfully modify the application or read the full private key in memory for the regular operation, but at that point would hinder any one admin to have access to the full key to use outside of the system. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aut disce aut discede Either learn or leave signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PCI DSS compliance
So would I! At this point, our company must achieve PCI DSS compliance before year end, and the road to that necessity leads through this auditor, who insists that PGP satisfies all requirements. There is no explanation that he shares with us. ~ Mike On Thu, Nov 10, 2016 at 8:27 AM, Mark H. Wood wrote: > I would be interested to hear this auditor's explanation of how *any* > completely automated software system can protect private keys from a > human with access to the system. > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PCI DSS compliance
I would be interested to hear this auditor's explanation of how *any* completely automated software system can protect private keys from a human with access to the system. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PCI DSS compliance
Yes, our company has been doing all four of your suggestions for years, including written policies and procedures, and we passed all prior years of PCI DSS auditing without incident. Near as I can tell, nothing has changed in this regard in PCI DSS standards in the last twelve months, to which our auditor agrees. You can find his non-member post here: https://lists.gnupg.org/pipermail/gnupg-users/2016-November/057009.html He says that PGP has some mechanism that satisfies this requirement. I haven't touched PGP in more than four years. Do they have something new? ~ Mike On Wed, Nov 9, 2016 at 2:54 PM, F Rafi wrote: > Probably out-of-scope for this list but, if the process is automated you'd > want to reduce the number of people with access to the keys to only staff > with need-to-know. Usually that translates to IT support / administrators. > Beyond that safeguards against people (specifically administrators) cannot > be technical controls. They have to be policies, procedures, and > monitoring/audit. You should demonstrate that: > >- You are doing background checks against employees with access to the >keys >- Those background checks look at issues like debt >- You have security policies and procedures that dictate use of >well-known security best practices >- You have a security awareness program that ensures that employees >are reminded of best practices >- You keep a log of whoever is logging into the system to access the >key > > You just have to trust your employees at some point. None of this > mitigates a rogue insider with access to the keys. > > -Farhan > > > On Wed, Nov 9, 2016 at 11:16 AM, Mike Schleif > wrote: > >> During our current annual PCI DSS audit, our auditor complains that a >> human being can access the company's private key and, thus, a human being >> can decrypt sales files containing credit card information. >> >> All production processes are fully automated and run as non-privileged >> user. >> >> We use GPG encryption for all file exchanges between this company and >> banks, and between vendors/clients and this company. The latter is the >> issue. >> >> What can be done about this? >> >> Please, advise. Thank you. >> >> ~ Mike >> >> >> >> >> ___ >> Gnupg-users mailing list >> Gnupg-users@gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
