3. Challenges with PCI-DSS Requirement 3: (Encrypt at Rest) “Protect stored cardholder data” Crypto-key distribution Requirement 4: (Encrypt in Motion) “Encrypt transmission of cardholder data across open, public networks” Requirement 8: (Strong Authentication) “Assign a unique ID to each person with computer access”
4.
5. We distribute Crypto keys to web users We hide crypto in digital pictures Steganography! User credential contains (AES encrypted): RSA-1024 user key pair (public-private) RSA-2048 public key for BunkerMail application Dual digital signatures for Authentication
6. Authentication Strong, Multi-Factor Authentication Picture = Virtual Smartcard Password is never transmitted or stored Bi-directional Authentication Sessions are encrypted using unique AES key exchanged upon Authentication (via our PKI) HTTPS used in addition, (redundant) globalcrypto.com/knowledge-center-overview
8. Encryption—end-to-end Private Note and Attachments are encrypted with unique AES keys. AES keys are encrypted with BunkerMail public key (RSA-2048). BunkerMail decrypts the AES keys and re-encrypts them with the public key(s) of recipients AES keys are escrowed if a user is not in the system (no public key yet)
9.
10. Ideal technical solution Encrypts at rest Encrypts in motion, end-to-end Provides audit logging, robust audit trail Housed in a secure data center Provides encrypted, automated archival Enforces strong, unique access controls Simple to use
Hinweis der Redaktion
PCI-DSS places many requirements on companies that handle Payment Card Information.BunkerMail addresses three main requirements with one technical solution for sending messages and files across company boundaries.Requirement 3 deals with Encryption at Rest. When you email or FTP a file to a business partner the file may be encrypted by HTTPS or SSL during transmission, but when the file is uploaded to a server often it is stored in an unencrypted state. End-to-End Encryption is an answer for this problem, but you have to distribute cryptographic keys to each user. BunkerMail makes this simple.Requirement 4 deals with Encryption in Motion. Most secure applications use HTTPS or SSL encrypted email sessions and cover encryption in motion. BunkerMail takes this a step further and authenticates the channel to thwart phishing and man-in-the-middle attacks.Requirement 8 deals with Strong Authentication. Users should be uniquely credentialed and multi-factor authentication should be used where possible. BunkerMail employs a strong, bi-directional multi-factor authentication that is simple to use.
GlobalCrypto recognizes that cryptographic key distribution is a hard. Certificates and key files are alien to end users and complex to set up.BunkerMail distributes crypto keys to end users by hiding them inside of digital images. Web technologies such as .NET and Flash are used to seamlessly store these images on the end user’s machine. End users hold these credentials on their computers which contain:-An RSA-1024 bit key pair (public and private keys) for the end user.-An RSA-2048 bit public key for the BunkerMail web application.-Partial digital signatures for the user and the web application for Authentication purposes.All of this cryptographic materiel is stored encrypted with AES where the key is a password. Note that the password is never transmitted or stored.
BunkerMail’s image-key is essentially a Virtual Smartcard with a password.The web application stores the image on the user’s machine for later use and recalls the image for authentication.Users only have to type in their password on an enrolled machine.The password is used to decrypt the partial digital signatures as well as the cryptographic keys.Authentication takes place over a secure channel via a session AES key that is exchanged using BunkerMail’s keys. This thwarts phishing and man-in-the-middle attacks that may plague HTTPS. HTTPS is used as a redundant protocol, but is not necessary.See our knowledge center at www.globalcrypto.com for a more in depth study of our authentication.
Here is what the user sees at authentication time. The web server retains a copy of the right-hand side of the image with partial digital signatures.When the user enters a password, the left-hand side is unlocked and transmitted to the server over a secure channel. If authenticated, the web server sends down an unlocked right-hand side of the image and the user is authenticated.The user sees both sides of the image come together and is logged in.
All information is sent as XML through previously authenticated and encrypted sessions. Encryption in motion is always maintained.However, some information is encrypted end-to-end:--The Private note is a message field for Rich Text and is encrypted end-to-end.--Any attachments are end-to-end encrypted.Each attachment and the private note are encrypted with a unique AES key.The AES keys are transmitted to the BunkerMail server using the Server’s public key. BunkerMail re-encrypts the AES keys using the recipient’s public keys.BunkerMail will escrow any AES keys that are bound for users who have not previously established an account and therefore don’t have a public key yet. Upon registration, the AES keys are re-encrypted using the new user’s public key.
We have a great technical solution to solve file transfer and sending of messages in a PCI regulated environment.We have solid cryptographic security and provide a simple user experience.Try us out at www.bunkermail.com
