Sometimes my Java program needs to send a .dll or .so file from client computer to remote machine. Is there a possibility to ensure that this .dll (.so) file is really created by me and not by some hacker? Firstly, I thought that digital signature (java.security package) would be my first choice, but I cannot verify signature in the remote machine, because Java may not be available there. Are there any other choices?
What you are trying to achieve is knowing as non repudiation. That is:
A service that provides proof of the integrity (nobody has modified your file) and origin of data (you are the genuine creator of the
file).
An authentication that can be asserted to be genuine with high assurance.
It's not about Java or C# or the language itself, it's a concept that doesn't depends on the programming language you are using.
Every language has it's own classes, libraries, mecanisms... for dealing with that, some in a better or easier way than others.
Specifically in Java, you can start taking a look here. The steps you need:
Generate a pair of keys (only done once).
Sign every document you create on client side (that ensures nobody can change it, nobody can take it's ownership and nobody can refuse the ownership of the file).
Send the document and it's signature.
On server side, verify the validity of the signature against the provided document.
If you only want to check if the file hasn't been modified you can use a simple digest mecanism without signing, just creating a hash (don't need to create certificates, validate signature...) and verify later will work, BUT be aware that with only hash, you can't check who is the author of the file, only that the file hasn't been modified since it's hash creation.
Related
I'm thinking how to protect the JAR from reverse-engineering.
(Question 1):
If JAR is signed by signature, is the signature able to protect the JAR? If not, then what is the purpose of signing?
(Question 2):
Android APK can be signed by platform signature, and It is impossible for extracting the platform signature from the APK itself.
From this point of view, I think signature can be used to protect something. But why can we decompile any APK even it is protected by platform signature?
Think about your own signature, that you write with a pen. Does signing a piece of paper make the contents of the paper somehow impossible to read?
No: it simply gives somebody reading the paper an indication that it was written by you (or you agree with its contents, or whatever).
And so it is with signing a jar: all it does is gives people an indication that you (or people you have authorized to use the signature) produced it, in order that nobody else can change the jar contents and present it as "authentic".
Signatures will not help you to stop reverse engineering.
If JAR is signed by signature, is the signature able to protect the JAR? If not, then what is the purpose of signing?
If you sign a contract, does that prevent any of the involved parties from breaking the contract?! Nope, it doe not. The signature is simply something that (theoretically) legally identifies you.
And that is the whole point of signing software: to tell users of the software: "this is my delivery, you can trust it, because I signed it (and nobody else can have changed it)".
Signatures do nothing to protect your content from reverse engineering. They are solely useful for users of your content, as they can be "sure", that they are really using your content, and not something that a third party faked and only claims to be your delivery.
The only kind of protection is to look into obfuscating your JAR file content. There are tools for that (especially on Android). Nonetheless obfuscation for Java isn't exactly perfect. See here for example.
If JAR is signed by signature, is the signature able to protect the JAR? If not, then what is the purpose of signing?
As the others have pointed out, it prevents others from distributing their own copies of your code under your name/brand. For example, suppose you write a calculator and post a signed bytecode on github, then I can't write my own bytecode and claim (without getting caught that its a false one, unless I find the key with which it was signed, which itself is very very ... very unlikely) that it is a copy of your calculator.
But why can we decompile any APK even it is protected by platform signature?
Because, it does not prevent us from decompilation. We can get the source code from such APKs but, we cannot like put our own arbitrary code in its place and makes others believe it is same as yours.
Put in plain terms, a signature is a proof of source and authenticity of a code, nothing more.
Edit:
Why can't we extract the original signature from the APK? Why is it impossible?
Because the signature is a hash, generated using a cryptographic hash function and a key that only you hold (called private key) and a public key, which is freely available. Since that private key is with you and assuming that you used a powerful cryptographic hash function, it will take a lot of time for a person trying to impersonate that key to find that key by directly trying all the hashes possible, which is usually the only possible way unless you have a clever work-around to find the key. The public key is openly available and is used for verification of the authenticity of the signature.
Can we use this mechanism for protecting our JAR?
Depends on what you are trying to protect. If it is impersonation by somebody else, then yes, for sometime, as long as they do not stumble upon the key by some way. As seems for obvious, it is no good against reverse engineering
I have a old projects developed by java and that old project made by Jdk 1.4 version.
This is single application java program.
Currently server and database configuration is written by .ini file.
but That is not really good for security because everybody can see this file physically.
Do you guys have any way to hide perfectly instead of using .ini file.
I think this is two way.
1. Make properties class in side of project and make .jar files.
- I can make .jar file but also I can decode it.
2. Separate Back-End server and communicate.
- This way I have to fix too many source code. So I am not sure it's good or not.
- Also what is this concept for specific we are calling in Java environment?
And anything else please suggest to me
Thank you!
The least protection you can provide to your configuration file is encrypting it.
Make properties class [inside] of project and make .jar files.
As I pointed out in the comments, you should never place sensitive data in compiled files. For one, it makes your design quite unflexible: If you decided to change your server password, for instance, you would also have to change your compiled files. As a second and more important reason, saving configuration data in compiled code is insecure; especially for Java, there are decompilers out there which can be used to decompile and thus retrieve the sensitive data.
Separate Back-End server and communicate.
I do not understand what is meant by this so I will not comment on it.
A means to secure your files is encrypting them; this is the least layer of protection though. When you login to your server sent the encrypted password to your server and the server, knowing the encryption key, will be able to decrypt the password and check whether the password is valid. While the last part may seem to be obvious, I insist on communicating that to you.
However, you should not rely on encryption solely. Furthermore, if the information you are protecting is not client specific, such as their login credentials, you should not store it on the clients computer in the first place; anything can happen on the clients computer - the client may even be the one trying to crack the your sensitive data. If you do not have to, do not store it on a computer you do not have control over. I do not know you circumstances, so there are hardly specific answers I (and the community) could provide.
I hope this answer helped you
I'm looking for a way to digitally sign a shared library so I can verify the authenticity of said library. My proposed solution was to hash the library and store this in the Java file that loads and calls the library but the problem is that this will fail if the library is updated in the future (unless all applications using the library are also updated).
I was thinking it might be possible to instead insert a hash of the library that has been signed with a private key to, for example, the end of the .so file so that this signed hash can be trusted and does not need to be stored in the calling application for verification. Is there any support for this in the Android APIs and will inserting data into the library in this way potentially cause problems for the library loader?
If your library is not being installed in /system/lib, it is normally used by one application - the one which had the library packed into its APK, and the typical update process will involve both the C++ library and the Java app. Therefore your verification does not need to survive updates.
On the other hand, the standard authentication techniques apply to library signing as well. E.g. add a new API "GetVersion(int salt)" which will return the shared secret (which may be the hash of the same file), "salted" with the random input. Now, you make reverse engineering your signature harder, because no man-in-the-middle analysis cannot give them a clue.
This may be easier to implement than looking for a signature at fixed offset of the library file, and harder to work around.
At any rate, appending an arbitrary blob at the end of a shared object will not cause problems with the loader. You can add the custom step of modifying the .so files in your Android.mk files. You must do it during or after the install step, which strips the debug info from the library.
I have made a java project and want to deliver it to a client but I don't want to deliver it as a jar file as the client can see the source code easily by unpacking the jar file.
How can I pack my java project so client cannot look at the source code or cannot change the source code?
One more thing, Can I integrate a key functionality so that client can only access that software by first registering it with the key provided by me?
Second, can I integrate another functionality through which the software can run only on a single machine through that key?
Remember, the software should still have the cross-platform functionality and if it is not possible then how can I made it for Debian Linux as I have made it on Windows.
To your first point. Why not only jar up the class files? These are in byte code so the client will not be able to view the source.
As to providing a key. This can be done and there are libraries that allow this, but be careful as , to my knowledge at least, there has yet to be developed a DRM system that hasn't been cracked. and most users do not like software restricting what they can do. The same point applies to your third question.
Obfuscators
There are some simple things you can do to make it a bit difficult for a client to get hold of your source code and to enforce per-host (etcetera) licensing. For example, obfuscators make it harder to reverse engineer bytecode files, and license managers support a range of restrictions based on the "keys" that you generate and supply.
The problem is that none of these protect you against someone who is determined to subvert the restrictions are trying to impose. For example, no obfuscator can prevent someone figuring out where your code calls a license manager, and once they know that they can modify the code to subvert any license checking.
Short of locking down the entire execution platform (e.g. turning of the client's ability to run debuggers, read physical devices and so on), there is nothing you can do about this.
A more viable strategy is to include appropriate protections in the software license that you require the client to sign. And accept that there is a risk that you may need to take clients to court if they willfully violate the license agreement.
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.