The problem is following: I need to make sure, that after certain data encryption has been completed, there is no way of extracting the password/derived key from the applications memory (existing passwords/keys has been overridden). I know it's not an easy task. I think I can still do it in the core part of the application I implement myself.
But what about the calls to external libraries like the ones implementing JCA/JCE I can't do encryption without (let's say Bouncy Castle). How sure can I be that the library does not create clones or other objects I know nothing about, that could reveal the password after someone dumps the memory to analyze it off line.
Can I just tell the library to clear the memory it has been using? Or maybe there are other ways to solve this problem?
Currently impossible, and you cannot do this without platform support. The memory that the Java heap uses can be swapped out and in, the memory may be reclaimed without it being wiped. The memory may be copied around and the reference changed etc.
For shorter time frames you may be able to do this (in a non-testable way) on byte arrays and characters arrays, but even then you may run into trouble.
So the only way is to use a (FIPS certified) JCE provider (or other, proprietary API) with native support. The native code could be a (FIPS certified) software library that does clean up the key material. Or it could connect to a hardware security module (HSM) or other hardware device (smart card or TPM) that is compatible with your symmetric algorithm and/or key derivation method.
Related
I am working on a project which requires the secret key to be hidden somewhere in the Android app, so that it can't be taken out even after decompilation.
The requirement even states that the key should not be visible to the developer, that means it should be embedded into some pre-compiled library.
I have tried the following things:
Making Jar and obfuscating the jar, Which becomes unusable after that. And its useless method to work with Strings (it doesn't encrypt Strings).
Making C library and using that library(NDK). The strings can be easily read using linux commands. Example: '$ strings '.
I am trying to find out other ways by which this can be done.
Please help me with this. If you have any idea, please share. I would be more than obliged.
Thanks.
Anything that your app can do, can also be reverse engineered by a determined capable hacker, so don't expect some magic way to make this key perpetually secured.
If your goal is to supply an SDK that will be licensed to different developers, then the easy approach is to allocate a unique key for each developer, and let them take care of hiding it from hackers.
On the other hand, if I read your requirement literally, it is enough that the key string will not appear in plain text in the APK. The easy solution is to encode it. You can do something as easy as base64 encoding of the key, or as tricky as providing a C function that will calculate this key on the fly (so no traces of the key will appear in the output of strings).
It's a hard problem. You're fighting a battle against reverse engineering your application. There are tools that are build for this, notably DexGuard and Arxan. Arxan is really, really clever, but it will cost a lot more than a solution like DexGuard.
For aar and jar protection against decompilation you can use Quixxi. Of course the effort is about raising the overall protection as much as possible, impossible is nothing. But this solution joins the best of both the points you made. What happens is the following conversion:
input: unprotected jar file
output: java file calling the native layer
You [or the developer that will need to manage the app containing your library] can later integrate it as described in the same link. Moreover the entire app can be protected with the same tool if other parts of it will need to be secured
I want to replace PostgreSQL encryption function ‘pgp_sym_encrypt’ and ‘pgp_sym_decrypt’ mechanism with HSM (hardware security module). Can i implement it to replace existing algorithm with HSM.
If your client is paying you to find this out, it'd be nice if you would do some research and work on it, not just ask Stack Overflow.
The pgp_sym_ functions are in contrib/pgcrypto/pgp-pgsql.c. They're wrappers for decrypt_internal, and in turn around the functions exposed in pgp.h and implemented in the pgp*.c files.
You'll see that pgcrypto has its own OpenPGP implementation. That means it's not using GnuPG as a library, and therefore cannot simply use GnuPG's support for hardware security modules directly.
If you want support for HSMs, you will need to implement it yourself in the pgcrypto extension. You may be able to use libgcrypt and GPGME functions to help you out, and/or functionality in OpenSSL. It depends on what HSM you're using; it might just a client library that does most of what you want.
It may be simpler, if your HSM has a client library that has functionality you want, to wrap that with PostgreSQL user-defined functions and expose it to SQL as a new contrib module.
Either way, you will have to do a lot of reading and a lot of research. You will need to know the C programming language and be comfortable working with it. You will need to understand how user-defined functions in PostgreSQL work. If you can't manage any of that, you'll need to subcontract the work to somebody who does, give them access to a sample of the HSM in question, and pay them for their time. (No, I'm not fishing for work, I already have too much).
Many HSM's can be programmed some of them will undoubtedly be both Turing complete and have enough memory to perform your encryption function (whatever that may be). So the answer is "yes".
My app is written in Java.
There is a C++ library I need to utilize. I don't want to use JNI.
60 times a second, the C++ app needs to send the Java app 10MB of data; and the Java app needs to send the C++ app 10 MB of data.
Both apps are running on the same machine; the OS is either Linux or Mac OS X.
What is the most efficient way to do this? (At the moment, I'm considering TCPIP ports; but in C++, I can do memory mapping -- can I do something similar in Java?)
Thanks!
Yes, Java has memory-mapped files with the NIO framework.
If you're trying to avoid JNI because you didn't want to write stubs, you can also interface with C++ code (at least ones that are extern "C") using JNA. For best performance, use direct mapping (concrete classes with native methods, not a mapped interface)---see documentation for more details. :-)
Using mapped files is a way of hand-rolling a highly optimized rpc. You might consider starting with a web service talking over local sockets, using MTOM for attaching the data, or just dropping it into a file. Then you could measure the performance. If the data was a problem, you could then use mapping.
Note that there are some odd restrictions on this that make your code sensitive to whether it is running on Windows or not. On Windows, you can't delete something that is open.
I should point out that I have done exactly what you are proposing here. It has a control channel on a socket, and the data is shared via a file that is mmapped in C++ (or the Windows equivalent) and NIO mapped in Java. It works. I've never measured maximum throughput, though.
Sounds like shared memory would be the way to go. I believe the NIO libraries support that.
The question is WHAT do you want your program to do?
You should give a look at BridJ (and JNAerator).
It's a recent alternative to JNA with support for C++ and a special focus on performance.
Not directly helpful and will be interesting at least to develop but you could throw in an SSD/RAM drive accessible to both the Java and C++ application and have a sort of juggle between data ops in there with file-based locking and all that odd stuff.
What would make this scheme sort of manageable from performance point is that for this purpose Java NIO has ByteBuffer which is a high level representation of low level byte mapping on disk.
You should take a look at javolution.
They are using NIO direct buffers for data exchange.
In theory, this should be faster then plain JNI
since you do not have the overhead of passing
data through the argument list.
So I am working on a java application, and the customer has requested the ability to have features that which can be unlocked to make the application customizable based upon what their customer wants to pay for. So I am trying to come with ideas for doing this in a manner that will provide some level of security, but also general maintainability and readability.
I have been doing some searching around, and had some ideas of my own, maintaining an encrypted configuration file which could possibly be stored in a jar file that I could unload, repack, and load at run time.
Looking to see if anyone else has any interesting ideas on how you might do this. I have been doing some looking on google without a lot of success thus far.
Oh one last little caveat, the machines this java application is on may not have internet available to them. So running a license server doesn't seem like a viable option
I would suggest using some sort of dependency injection or runtime weaving aspects, so you can include new jar files that have the correct xml files or configuration files for new features.
I agree with coobird that including them and locking them is inherently risky as someone will eventually decompile your application and determine how to get all the features.
The only sure way to prevent "unauthorized access" to features that are "locked" in software is not to provide the code that one does not want the user to have access to in the first place.
Enabling extra features by unlocking using passwords, encryption (where's the key going to be? In the program itself?), configuration file can usually be defeated by someone who is determined to get to the code they want to execute.
At least unlocking using software means can most likely be defeated, if the code that is locked is already being distributed in the binary. One way that I can think of off the top of my head that seems a little secure is an hardware key dongle, or having important code that is stored on hardware, but not many people like the idea of having to plug in a piece of hardware to use the software.
When it really comes down to it, don't have features in the code itself which is only disabled by some software flags.
I suggest you build a trusting relationship with your customers. Either that, or bundle a USB key dongle, but even these are not 100%.
If you are distributing software, any kind of encryption must be able to decrypt itself. You are essentially giving the customer both the lock and the key.
You could possibly implement the core product, and then have the additional features as plugins. You could put each plugin in a separate jar file. The customer could then distribute a bundle that contained the core application, and the purchased plugins. Thus the un-purchased functionality is not in any of the binaries.
Distribute the full set. Have them call you for the keys to unlock various features. (Use a simple encryption scheme so that the keys are of reasonable length and can be conveyed over the phone.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am working on project that must need to protect data (revealing code is not main problem) files. We are using Java + Netbeans. Is there any facility that will create jar in encrypted format? We are also using sqlite for database - so putting text file in encrypted format is not proper option for us too.
Creating encrypted JARs is not possible, since the executing JavaVM has to somehow be able to read the data it wants to execute.
And similar to a VM it would be possible for anyone with the proper tools and know-how to extract all data from the JAR.
If it would be possible to encrypt the JAR, you would also have to provide some decryption-key or facility to the client which wants to execute the JAR which defeats the purpose of encryption at all.
The best you can get is obfuscation, but that's no real security or hurdle for the ambitious attacker.
Kosi2801 is pretty much right on. The only thing I can think of you could do is the following, but it's ugly.
Ship a small standard JAR and an encrypted data file.
When the JAR runs, it decrypts (some) of the encrypted data file into memory (like the directory of where data is in the JAR, basically a simple in-memory file system of pointer/length pairs)
Set up your own class loader that, when called, gets the right encrypted bytes from the JAR (using the pseudo-FS table described in #2), decrypts it, and then loads the class data from there
This would let you load the classes. You could do the same thing (without the class loader) to load other resources.
While fun to implement (for those who like a challenge) there are a few problems with this:
You'd need to be able to decrypt the stuff, so the user would either have to enter a password every time or something similar. If the JAR knows enough to decrypt it's self, then anyone can look at it and figure out how to decrypt things. This could be mitigated by contacting a known-good server over the Internet to ask for the decryption key (as long as you make that process secure). Of course this requires an active 'net connection any time someone wants to run the program.
Everything ends up in memory. Without a custom JVM that handle tiny bits of encrypted byte code (as Cameron McKay mentioned) the classes will end up decrypted sitting in main memory at some point. Unless you rely on the OS to prevent other people from reading that memory, you've already lost the battle to anyone with a little time on their hands. Same issue for resources (such as images/fonts/etc) that you try to read out of some encrypted store.
So you can give people the run-around and make things harder, but in the situation you've given all you can do is try to make it not worth the time the other person will have to invest.
Software protection is tough, especially in something like Java that can easily be decompiled and can't alter it's own code like C/Assembly could. There is a reason some of the most expensive software out there requires hardware dongles or comes locked to a certain CPU or other hardware.
I agree with Kosi2801. Class file encryption is just imitation of security (see http://www.excelsior-usa.com/articles/java-obfuscators.html)
Use of custom ClassLoader's can break the application, e.g. in Application Servers.
There is the better way: use encryption of String constants in a class files. The most of commercial obfuscators have this function, for example Allatori, Stringer Java Obfuscation Toolkit, Zelix KlassMaster, Smokescreen, DashO (super expensive). The Stringer Java Obfuscator has call context check and integrity control features which makes protection really hard to hack.
The most secure way is to store and execute parts of bytecode on an external device like JavaCard.
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
In general, there is no way to do this in a secure fashion, if you want the app and its data to be self-contained. However, you can certainly encrypt the files and decript them with a key buried in the code. A determined hacker can get it, but if that's not what you are worried about, then fine. If you do this, remember that encypted data cannot be compressed, so compress first, then encrypt.
If you genuinely need the data to be secure (eg, confidential data), you will need to encrypt the data with a key and supply that key to the app my some external means, such as putting it on a thumbdrive and getting that to the user by means of a secure courier.
Another possibility it to make the data (or the key) available over SSL, and use a good authentication method to verify who your user is.
In general - it's not possible for any system to be perfectly secure, but it's also not nessesary. A system only needs to be secure enough to discourage the attackers that you think will be trying to crack it.
Another option would be to make a custom JVM that decrypted the JAR on the fly. But the same problem remains: at some point the JAR Java classes have to be decrypted to be run by the JVM, and at that point they can be captured and de-compiled.
Not to mention that having a custom JVM would then require all your users to download that JVM as well.
You could use the CipherOutputStream and CipherInputStream to serialize Java objects to disk in an encrypted format. This may an option open for saving data.