I'm reading here
and also http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation
and also itext's white paper on digital signature.
here's a sniplet of itext's sample code:
BouncyCastleProvider provider = new BouncyCastleProvider();
Security.addProvider(provider);
KeyStore ks = KeyStore.getInstance("pkcs12", provider.getName());
ks.load(new FileInputStream(path), pass);
Question: What is a security provider and what is it used for? Itext code uses the bouncycastle provider. Is it basically code used to hash the pdf and then later the private key is used to encrypt the hash? And what is the role of the "Security" library above where it says Security.addProvider(provider).
Thanks.
A security provider provides algorithm services to the runtime. These are implementations of algorithms, for instance Bouncy Castle adds a lot of algorithm implementations that extend CipherSpi (Spi means service provider implementation). Oracle provides CipherSpi classes as well, but it is limited to certain algorithms. These services are also used to implement e.g. KeyStoreSpi for "pkcs12", to make this more specific to your question.
Besides providing support for extra algorithms, providers can also be used to extend the functionality of the API, provide support for hardware tokens (smart cards, HSM's), specific key stores, faster implementations etc. . Bouncy however is mainly used because it extends the number of algorithms available. Usually you don't specify the provider name when requesting an algorithm, letting the system choose for you. But sometimes the algorithm provides (or provided) some specific advantage to the one in the Oracle providers (e.g. "SunJCE"). It may make sense to explicitly choose the provider as in your example code.
The Security class is a register. It can be used by the system to look and list the services present in the provider, using their names (as string) and aliases. To have an idea how this works, please try my answer here.
Related
so I am working on a software that will have to eventually communicate with one or more servers. I am experimenting on implementing Json Web Tokens for specific parts of this communication (basically not for authentification, they will be access tokens mostly).
For some reasons, I would want to include sensitive data as a part of the payload (not highly sensitive, more like infos that are better not be shown for privacy reasons, but not critical for the application integrity).
After reading the JWE specs, and considering the available time i have to do this, i would like to spare the task of building a proper JWE for the moment, and just use a custom function to encrypt the payload before creating the JWS. A proper JWE would be then delayed until next version of the software.
Is it totally to be avoided? Can i use this as a temporary solution? Or is it rather a sign of bad desing of my communication ways?
EDIT - I preferred editing this topic, as the new question is closely related to the first one, but a bit more precise and specific:
I went on with proper security specifications and tests with it. Now that i came up with what seems to be a good encryption solution, and read quite a lot more on the subject, it seems that the approach I started to work with would be valid: it is stated in many places that encryption does not cover the content integrity, so that the message must go through a MAC (after encryption).
_So, let's take the initial question in the inverse order: now that i have a properly encrypted message, and then need to MAC it, is a JWS built with the HMAC algorithm a valid MAC? Or is it just language abuse to call it a HMAC JWS?
We have a business requirement to keep credit card data. What is today's (Nov 2013) state of the art algorithm to encrypt credit card data that will be saved on disk?
Additionally, I'd appreciate pointers to Java libraries that implement these algorithms
Note that we are PCI compliant and we already store credit card data. I am doing a review to make sure that our encryption method remains state-of-the-art
I recently just left the credit card industry as a developer to work in security in non PCI compliant field. BCrypt is a great choice. It allows a one way hash as well as a work parameter that forces time per attempt. This allows you to stop brut force attacks.
I would use one of the block ciphers approved by ISO/IEC 18033: AES, Camellia, and SEED.
It's hard to go wrong with AES256.
Just go ahead with AES 256 but make sure you choose right mode. I don't agree with comment "It's hard to go wrong with AES256." Check out - https://pthree.org/2012/02/17/ecb-vs-cbc-encryption/
Needless to say, you need to take care of key management and avoid any issues with IV- a message "hello world" encrypted with a key1+IV1 combination will look exactly the same in ciphertext every time you run your encryption. So make sure you are choosing your IVs randomly from a large entropy pool
From Java implementation perspective, Java has native support for AES encryption. Just make sure if you are using 256 bit encryption, you have the right unlimited strength JCE files - without these JCE files which provide crypto methods, you will be limited to 128 bit encryption.
Checkout this if you don't want to reply upon these JCE files available on server running your application.
As #gauravphoenix points out, it is actually quite easy to go wrong with AES. The AES algorithm itself can only securely encrypt exactly 16 bytes of data if you give it a totally random key. If your problem is anything other than that (and almost everyone's problem is something different than that), you need to add more pieces to it. Specifically you need to choose an appropriate mode, configure that mode correctly, properly generate a key, and protect against modification. AES does none of this for you automatically, and unfortunately, most example code on the internet does it incorrectly.
There are a few libraries that attempt to bundle all of these details for you so that you can just make the silly "please encrypt this data" call that most people would like to make. I maintain one for iOS called RNCryptor. There are a bunch of ports of the format to other languages, including a Java implementation called JNCryptor.
Another good "whole solution" AES implementation is aescrypt, which includes a Java implementation.
Note that the most important technical(*) step of securing the data is not your selection of algorithm or format. It's how you manage the keys. If you store the key on the same disk as the credit card numbers, or hard-code it into your software, then it doesn't really matter how strong your encryption is. The state of the art in key management is called an HSM (Hardware Security Module). Companies like SafeNet make them. They can be rack-mounted, plug-in cards, or even USB dongles. I've worked with the Luna, and was generally pleased with it, but there are several options on the market.
(*) While key management is IMO the most important technical step, it is by far not the most important step in securing credit cards (or anything else). The most important step is having procedures in place that encourage secure design, pre- and post-release security review, and a commitment to remediation of security findings.
Let's suppose we have an open source project running in a server.
Is there a common way to prove users that we're using the same code as the one published?
There is never an implicit guarantee that the remote service is what's described in its manifest, though generally the reputation of the service is what's directly considered.
What's more, SaaS itself is just a delivery model, and doesn't necessarily define a set of protocols or contracts between a client and a service. It merely defines an approach to building and serving a public platform. It's a term more relevant for describing the building process of a service and it's intended market than it is for describing the nitty-gritty operational details.
If such a thing needed to be implemented as part of the contract between the client and server, one could look at implementing a native hashing solution using HMACs. An identity mechanism could be implemented using salted access tokens similar to OAuth, but using the files of the codebase to generate the checksum. This would guarantee that if the code executed properly once, it would be the same code running so long as the hash generated did not change (though there's once again no guarantee that the hash being publicly exposed was properly generated)
Such a thing would sound redundant however, on top of the SSL security most services generally tend to use.
The long and short of it is that if you have concerns about the service being offered over a public API, then there is probably a pretty good reason its reputation precedes it.
I need to send data from an Air application, using a certificate.
This certificate is to be provided by the user through a USB Key.
I've got a lot of questions regarding this.
Is it possible to do what I'm looking for?
If yes, is it possible to do that only with the Flex/Air sdk or should I use Java or some other language to load the certificate?
Would anyone have a link where I can learn some more about this? I've been looking through the web, but haven't really found anything useful...
For the certificate stuff, you may take a look at the as3crypto library, which is doing an awesome work in implementing various cryptographic and security related algorithms in AS3. I've used this particular library to do data signing and verification, using an external X.509 certificate.
The implementation in this library is pretty straightforward, and you shouldn't be confused about it, if you are a little familiar with cryptography and the whole keys/signing/certificates world.
[Edit] If you are not, you might want to take a look at the Digital Signature page on Wikipedia, which is a pretty good introduction to this world. Also, because the AS3 implementation of RSA is quite slow, if you want to sign a large number of data, you may want to sign hash of the data instead of the real data. For the practical code to do this kind of stuff, there is some code sample in the demo of the library.
Also, as you mention that your certificate is coming from an USB drive, you should be aware that using AIR 2.0, you might be able to monitor plugging and unplugging of mass storage devices. That might be cool for your application.
Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?
There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.
Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.
3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.
As to what I'm trying to do it's not:
Store passwords + salts as one way hashes for authentication,
Choose a strong symmteric algorithm for data encryption,
Avoid needing to store private data in the first place.
Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.
All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.
I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.
I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.
ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read. (X9.17 is updated yearly, and latest version is now: NIST SP 800-57 Pt. 1 Rev. 4 )
When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.
From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.
My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.
Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.
Good luck. I hope you also find it an interesting challenge!
Have you seen NIST SP 800-57, Recommendation for Key Management?