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.
Related
In my project (windows desktop application) I use symmetric key in order to encrypt/decrypt some configurations that need to be protected. The key is hardcoded in my code (C++).
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
Is there a way for better security for managing the key?
Are there open source or commercial products which I can use
Windows provides a key storage mechanism as part of the Crypto API. This would only be useful for you if you have your code generate a unique random key for each user. If you are using a single key for installations for all users, it will obviously have to be in your code (or be derived from constants that are in your code), and thus couldn't really be secure.
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
100%. Assuming of course that the key protects something useful and interesting. If it doesn't, then lower.
Is there a way for better security for managing the key?
There's no security tool you could use, but there are obfuscation and DRM tools (which are a different problem than security). Any approach you use will need to be updated regularly to deal with new attacks that defeat your old approach. But fundamentally this is the same as DRM for music or video or games or whatever. I would shop around. Anything worthwhile will be regularly updated, and likely somewhat pricey.
Are there open source or commercial products which I can use
Open source solutions for this particular problem are... probably unhelpful. The whole point of DRM is obfuscation (making things confusing and hidden rather than secure). If you share "the secret sauce" then you lose the protection. This is how DRM differs from security. In security, I can tell you everything but the secret, and it's still secure. But DRM, I have to hide everything. That said, I'm sure there are some open source tools that try. There are open source obfuscation tools that try to make it hard to debug the binary by scrambling identifiers and the like, but if there's just one small piece of information that's needed (the configuration), it's hard to obfuscate that sufficiently.
If you need this, you'll likely want a commercial solution, which will be imperfect and likely require patching as it's broken (again, assuming that it protects something that anyone really cares about). Recommending specific solutions is off-topic for Stack Overflow, but google can help you. There are some things specific for Windows that may help, but it depends on your exact requirements.
Keep in mind that the "attacker" (it's hard to consider an authorized user an "attacker") doesn't have to actually get your keys. They just have to wait until your program decrypts the configurations, and then read the configurations out of memory. So you'll need obfuscation around that as well. It's a never-ending battle that you'll have to decide how hard you want to fight.
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.
I need a utility to be given to my customer having site name A.com where he can decry-pt messages passed from my own site (i.e. B.com), which is build in Java technology.
Utility should be independent of technologies used by customer web site for their development.
Question: What technology should be used for developing such a Utility ?
Note: I have read that JavaScript is not good for cryptography.
The best option would be to use an existing, tried-and-tested protocol. TLS is a good choice for securing communication between two parties.
If, for some reason, you cannot use an existing protocol, you'll have to design your own, and describe it in such detail that others can implement it on their platforms. But this is very far from ideal for several reasons. Designing cryptographic protocols is hard, and even experts regularly get it wrong. Implementing cryptographic protocols is hard too, and experts often also get this wrong. There is simply no way a non-cryptographer could design or implement a secure protocol.
i got a little program that i want to send it to some other peoples.
But i want to prevent that they can easily share it with others.
Is there some easy protection i can use? It doesnt need to be unhackable, just a little protection that you cant just send the app around.
It can't be uncrackable anyway :) There are lots of different protections that you can use, but it always come down to the skill of the reverse engineer.
A pretty standard technique is to pack your software with a packer like asprotect, armadillo, aspack, upx, there are tons of options. This would make it difficult for them to hexedit your software, debug and disassemble it.
If you want to use a serial protection, there are lots of things you could do. One of my favourites is using the key to dynamically decrypt preencrypted blocks of code and execute them. This is called polymorphism and along with self modifying code, it can be a pretty frustrating protection.
If you want to keep things really simple, you could just create a xor protection where correct_serial XOR constant == another_constant. Using constant XOR another_constant, you could simply create a key.
Really tons of things to do here, it's always a matter of taste and knowledge.
There are lots of free solutions, most are crackable. In spite of popular opinion, modern dongles can be 1) trouble-free and 2) uncrackable. But they can cost $25-$100 each, so not a good choice for low-value software.
the use of keys is frequently tied to symmetric key encryption of the .exe so it can't be easily copied. The key is unique to the installation, and can be created by tying it to the machine characteristics like CPU serial number, MAC address, HD serial number, etc. You can also build a small table of those fingerprints and register that user/SN with that table; then have the app "phone home" from time to time to compare to a server DB. Both these methods are crackable, but you said you weren't looking for something unhackable. Downside of HW fingerprinting is that it can fail when the user upgrades the net card or HD. then you have an unhappy customer because they paid for the license and it won't run.
There are MANY approaches to this, this is one:
Create an authentication web service.
Get your app to generate a unique key from something that identifies the machine.
This gets sent you you and you generate a companion key that your app can verify against its unique key.
As you can imagine this is not something you quickly add in. It requires infrastructure and management, which is tricky.