My system enables users to save their work as a draft. I'd like to encrypt the data before I persist it. I was working on this -
AESKey k = new AESKey();
AESEncryptorEngine a = new AESEncryptorEngine(k);
a.encrypt(byte[] data_input, int input_offset, byte[] data_output, byte[] output_offset);
I however need to persist an object. Is there a way to get a byte[] stream from an object? Also, which encryption standard should I be looking at considering the processor / memory limitations of a mobile device?
Thanks,
Teja.
You mention that you're going to persist your object; does that mean that you intend to place it in the PersistentStore? If so, you have access to some built-in protection.
You can use a ControlledAccess object to prevent any access from an app without your code signing keys. You can find more information here: http://www.blackberry.com/developers/docs/4.1api/net/rim/device/api/system/ControlledAccess.html
To persist an object, have your class implement Serializable and write the object to a file. See here for more info about serialization.
If encryption is necessary, you could just encrypt the file. I'm pretty sure Blowfish is the way to go for an embedded device. It uses very little memory and AES is a bit slower on an ARM based processor.
From what I can tell, the ControlledAccees routines don't actually encrypt the object, they simply make finding the persistent object really hard.
Does anyone know how to either truly encrypt an object, or turn it into a byte stream so that it can be encrypted using BlowFish/TwoFish/another encryption technique?
Related
I am tasked with implementing a dongle-based copy protection scheme for an application. I realize that no matter what I do, someone will crack it, but I want to at least make it a little more difficult than an if-statement checking whether a dongle is present.
My approach is to encrypt critical data that the application needs for proper execution. During runtime, the decryption key is retrieved from the dongle (our chosen model has some suitable API functions for that), the data is decrypted and the application is happy.
Of course, a determined attacker can intercept that decryption key and also get ahold of the decrypted data. That's ok. But what should be hard is to substitute their own data. So I'm looking for an encryption scheme where knowing the decryption key doesn't enable someone to encrypt their own data.
That's obviously asymmetric encryption. But for every such algorithm I found so far, the encryption (or public) key can be generated from the decryption (or private) key, which is exactly what I'm trying to avoid.
Note: simply signing the data won't help much, since (unless I'm totally misunderstanding such signatures) verifying the signature will just be another if-statement, which is easily circumvented.
So... any ideas?
The moment the private key is known to the attacker you won't have any secret information to differentiate yourself from the others.
To make it harder for the attacker: You might want to expire each pair (public key, private key) after an application specific time T and generate a new pair based on the previous pair both on the dongle and your own machine, independently. This way the attacker needs to have a constant access to the dongle to be able to encrypt his data with the new private key or to run his private_key_detection algorithm as often as T.
You probably want to run the decrypt on the dongle. There are a few pieces of hardware that help this (I just googled this one, for example.). There are likely many others....Dallas Semiconductor used to have a Java button that would allow you to run code on a small dongle like device, but I don't think they have it anymore.
Some of these allow you to execute code in the dongle. So maybe a critical function that is hard to recreate yet doesn't require high performance might work? Perhaps a license key validation algorithm.
Maybe you could include code in the dongle that has to be put into memory in order for the program to run. This would be a little harder to break, but might be hard to implement depending on what tools you are using to make your program.
You probably also want to study up on some anti-debugging subjects. I remember seeing a few publications a while back, but here is at least one. This is another layer that will make it harder to crack.
Dependency on an Internet connection may also be an option. You have to be careful here to not piss off your customers if they can't get your code to run without an Internet connection.
You can also check out FlexLM (or whatever it is called these days). It works, but it is a beast. They also try to negotiate a percentage of your company's gross profit for the license fee if I recall correctly (it's been years....I think we told them to stuff it when they asked for that.)
Good luck!
To answer my own question (somewhat), it is possible to do this with RSA, but most APIs (including the one of OpenSSL's crypto library) need to be "tricked" into doing it. The reason you can generate the public key, given the private key, is that
It is common practive for implementations of RSA to save p and q (those big prime numbers) in the private key data structure.
Since the public key (which consists of the modulus N and some exponent e) is public anyway, there's (usually) no point in choosing an obscure e. Thus, there are a handful of standard values that are used commonly, like 3 or 65537. So even if p and q are unknown, you might be able to "guess" the public exponent.
However, RSA is symmetrical in the sense that anything you encrypt with the public key can be decrypted with the private key and vice versa. So what I've done (I'm a monster) is to let the crypto library generate an RSA key. You can choose your own public exponent there, which will later be used to decrypt (contrary to the normal way). Then, I switch around the public and private exponent in the key data structure.
Some tips for anyone trying to do something similar with the crypto library:
In the RSA data structure, clear out everything but n and e / d, depending on whether you want to encrypt or decrypt with that particular key.
Turn off blinding with RSA_blind_off. It requires the encryption exponent even when decrypting, which is not what we want. Note that this might open you up to some attacks.
If someone needs more help, leave a comment and I'll edit this post with more information.
I found a "lua aes" solution on the web a while ago. And have some concern about its safety.
It states that:
-- Do not use for real encryption, because the password is easily viewable while encrypting.
It says this at its "file encryption test" script.
My questions are:
Why is that, how is it any different from encrypting a string and writing it to a file?
How could it be viewable while encryption? Is it viewable after encryption too?
Basically, Is it safe to use or not?
Is there anyone who can confirm this who has used it? I mailed the original developer but the email address was invalid.
Should I be using it at all?
I assume there are two reasons why that recommendation was made:
Strings are immutable in Lua, so there is no way to overwrite a string with different data
once it's created.
In Lua, objects are garbage collected. The garbage collector runs only at certain points in
the program, and the application has no way of telling when the garbage collector will run after there are no more references to the object. Until then, the password string will remain in memory by point 1.
See Java's case, which is similar to Lua:
Why is char[] preferred over String for passwords?
As you can see there, using char arrays instead of strings is a better way to store passwords, since arrays are mutable and can be reinitialized to zero when done.
The closest Lua equivalent to a char array is a table filled with numbers. Here the password is stored as a table, rather than a string, where each element in the table consists of the integer representation of each character. For example, "pass" becomes {0x70,0x61,0x73,0x73}. After the table containing the password is used to encrypt or decrypt, it is filled with zeros before it's unreachable by the program and eventually gets garbage collected.
According to your comment, I may have misunderstood. Maybe the "file encryption test" stores the password in plain text along with the encrypted file, allowing anyone with access to the file, even attackers, the ability to trivially decrypt it. The points above still apply, though. This is still only a guess, however; I can't know exactly what you mean unless you provide a link to the encryption library you mention.
I've taken a look at the AES library and the concern about the password being "easily viewable" occurs because the user types the password in plain text, through the command line or terminal, in order to start the Lua program, even though the output of the program contains only cipher text. A slightly more secure way of providing the password would be not to show the input (as is done in sudo) or to mask the input with dots or stars (as is done in many Web pages).
Either that or the points given above are perhaps the only logical explanation.
You may also try out alternate methods, like LuaCrypto, which is a binding to OpenSSL and is able to encrypt data using the AES standard.
We've had to extend our website to communicate user credentials to a suppliers website (in the query string) using AES with a 256-bit key, however they are using a static IV when decrypting the information.
I've advised that the IV should not be static and that it is not in our standards to do that, but if they change it their end we would incur the [big] costs so we have agreed to accept this as a security risk and use the same IV (much to my extreme frustration).
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
*UPDATE:*We are also using the same KEY throughout as well.
Thanks
Using a static IV is always a bad idea, but the exact consequences depend on the Mode of Operation in use. In all of them, the same plaintext will produce the same ciphertext, but there may be additional vulnerabilities: For example, in CFB mode, given a static key, the attacker can extract the cipherstream from a known plaintext, and use it to decrypt all subsequent strings!
Using a static IV is always a bad idea. Using a static key is always a bad idea. I bet that your supplier had compiled the static key into their binaries.
Sadly, I've seen this before. Your supplier has a requirement that they implement encryption and they are attempting to implement the encryption in a manner that's as transparent as possible---or as "checkbox" as possible. That is, they aren't really using encryption to provide security, they are using it to satisfy a checkbox requirement.
My suggestion is that you see if the supplier would be willing to forsake this home-brewed encryption approach and instead run their system over SSL. Then you get the advantage of using a quality standard security protocol with known properties. It's clear from your question that neither your supplier nor you should be attempting to design a security protocol. You should, instead, use one that is free and available on every platform.
As far as I know (and I hope others will correct me if I'm wrong / the user will verify this), you lose a significant amount of security by keeping a static key and IV. The most significant effect you should notice is that when you encrypt a specific plaintext (say usernameA+passwordB), you get the same ciphertext every time.
This is great for pattern analysis by attackers, and seems like a password-equivalent that would give attackers the keys to the kingdom:
Pattern analysis: The attacker can see that the encrypted user+password combination "gobbbledygook" is used every night just before the CEO leaves work. The attacker can then leverage that information into the future to remotely detect when the CEO leaves.
Password equivalent: You are passing this username+password in the URL. Why can't someone else pass exactly the same value and get the same results you do? If they can, the encrypted data is a plaintext equivalent for the purposes of gaining access, defeating the purpose of encrypting the data.
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
A good example of re-using the same nonce is Sony vs. Geohot (on a different algorithm though). You can see the results for sony :) To the point. Using the same IV might have mild or catastrophic issues depending on the encryption mode of AES you use. If you use CTR mode then everything you encrypted is as good as plaintext. In CBC mode your first block of plaintext will be the same for the same encrypted data.
what is the meaning of MD5CryptoServiceProvider and what it can do can any body tell me please?
It is a .NET Hash class. It allows you create non-reversible signatures of data, that are used mainly for matching passwords.
Rather use SHA256 and above nowadays though, as MD5 is not of much use anymore cryptographically, other than doing Hash checks on downloaded files.
EDIT for Example on SHA256:
byte[] data = new byte[DATA_SIZE];
byte[] result;
SHA256 shaM = new SHA256Managed();
result = shaM.ComputeHash(data);
This is a code example straight from MSDN (normal hashing). As you see, it is also quite simple.
Now using the CryptoProvider, check this link here, which is a forum post, but shows usage quite nicely.
It helps you take the MD5 hash of a stream. It's not ASP.NET specific, by the way - any .NET code can use it.
You generally use a hash function when you want to be able to verify that a piece of data presented at two different times is the same (e.g. for passwords or file consistency). MD5 isn't considered very secure these days - there are other hashes (e.g. SHA-256) which are harder to attack. (An attack generally consists of an attacker knowing the hash, and then finding some piece of data which hashes to the same value, but without knowing the original data.)
What is the best way to encrypt a value in INI file?
Using Encryption/Decryption key??
For what purpose? Security?
If you are trying to (e.g.) encrypt a plaintext password you should probably use some implementation of PKI. Remember though, that then key management becomes your problem. Just encrypting the value is not a panacea because the ini file is most likely on the local host's file system, presumably the same place you'll have to store your key pair. You've simply abstracted the problem down a layer. They won't be able to read your encrypted password directly, but if they can find the place you store your key pair they can decrypt it themselves.
To what effect? What are you trying to protect or obfuscate?
You could use one of the many two-way key encryption algorithms available for all platforms... But ask yourself why you're doing it in the first place. If you're trying to make something hack-proof, encrypting ini strings probably isn't going to get you that far because as soon as you decrypt the ini, the string is in memory. And the key to decrypt will be in your program. Childsplay to hack out.
If you just want to stop people editing a setting easily, don't put it in an ini. Choose a binary format that the user will have a hard time editing.
For personal scripts where I have an email password, I use
TinyEncryption.
I will put the passkey in the code itself. This prevents a casual snooper from just browsing through and picking up an email password.
The code is pretty simple too. Here it is in Python.
import random
import base64
def tinycode(key, text, reverse=False):
"(de)crypt stuff"
rand = random.Random(key).randrange
if reverse:
text = base64.b64decode(text)
text = ''.join([chr(ord(elem)^rand(256)) for elem in text])
if not reverse:
text = base64.b64encode(text)
return text
For more enhanced security, I use PGP, but you then have to prompt for a passkey. There's no setup that's perfect, it depends on what your needs are.
You could use any standard encryption algorithm with a key, and perhaps prefix the value with some random padding before encrypting.
However where do you plan to store that key then? Or are you going to get the user to enter a password and derive a key from that? If not then it would be fairly pointless to encrypt the value.
Do you need to decrypt it too? If not you can just salt and hash it.
If you do want to decrypt it, then Id say you should specify the language as well perhaps.
MD5 hash
Then you compare hash("password") with the ini_file.password hash