Java PKCS11 Standard for Crypto tokens - java

Hello I am trying to make an applet in Java which reads Smart Cards ( as Security Tokens) and I didn't manage to handle it at all. I already found this :http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunPKCS11Provider which should give me some details... but I have never added a provider in Java ... and I also can't find any of the classes mentioned there for the provider...
Thank you.

You shouldn't need to reference the provider directly. You ask the API for a particular algorithm and it finds the appropriate provider. PKCS#11 is quirky, though. You'll have to read the detailed doc very carefully. I strongly recommend writing the app to do something with a software provider first. For example, create a Java Keystore, create a key in it and sign it then verify the signature. Definitely write a positive and negative test case. In other words, show that tampering with the data makes the verification fail. Next, figure out how to use the PKCS#11 provider by changing your program to use it. Using the Java cryptography APIs is hard enough without adding all the complications of PKCS#11 and your specific smart card to the mix.

Related

How to ensure that file is created by me?

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.

Securing key into Android app from decompilation and developers

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

‘pgp_sym_encrypt’ and ‘pgp_sym_decrypt’ mechanism with HSM (hardware security module)

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".

is it possible to force a(n embedded) JVM to only execute certain digitally signed apps?

A bit of a noob-who-tries-to-get-a-glimpse-of-something-without-making-homeworks-first question...
Suppose I'd like to include a JVM on a closed source O.S./hardware to be able to provide extended functionalities to customers with addon java applets, and that I'd want to be the only available source to develop and sell addon apps... then is it feaseable to easily implement such a mechanism by simply forcing embedded JVM to only allow execution of apps signed with my digital sign?
In other words I'd just like to know if this is an easy to implement, already proven to work, widely accepted path or just plain BS (for reasons you are free to not tell!) :)
It sounds like what you're wanting is class signing. The startup code for your application can install a SecurityManager to ensure that only classes signed by keys matching some particular criteria can be loaded.
Adding my own answer to get feedback on the following solution, which seems to be the most fitting with my question:
Could Java system policy file be the answer?
As far as I can understand from reading the documentation at http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html you can basically implement code execution permission policy in 2 ways:
1) implementing and extending permission policy at runtime (what #chrylis refers to).
2) using a default system policy file (java.home\lib\security\java.policy)
The second approach seems easier to implement and kind of more "static" which is a good thing given my use-case because I only need JVM to check that digital sign of app is mine to allow it to run, and will never ever need to extend this policy in any possible way.
So I am not sure yet but given my prerequisites this approach might be what I was looking for in my question... If you have any thoughts just add them, thanks.

Symmetric-key encryption algorithm

I'm looking for a secure symmetric-key encryption algorithm compatible with both JavaScript and Java.
I've tried implementing one but I had some encoding issues.
You don't want to encrypt with JavaScript, especially on the client-side where it is open to tampering, and has no cryptographically secure random number generator.
I've tried implementing one but I had some encoding issues.
You tried to write your own encryption algo? You've gone against everything that the security world hold dear. No. Actual tutorials that explain how encryption works are so scared that people are going to screw things up because they don't understand the math behind it, I've actually seen this in one of them:
If you don't understand encryption, things like, what "cryptographically secure pseudo random number generator" actually is, and common attacks on it, you shouldn't do that.
If you don't understand things like side-channel attacks, you shouldn't do it.
If you don't understand what's going on in crypto and have read at-least two books on it you have no business implementing it.
Crypto is not a magic black box, it's something that is very VERY easy to screw up, even without touching any bit of code in a packaged solution.
What should you do? Forget about JS encryption. I know, I've tried it myself. It's a waste of time. Learn from my mistakes.
Go get an SSL certificate, SSL is the best way for us to encrypt messages on the transport level from a server to a client. It's about as secure as you can get. If you face an advesary that can defeat SSL, trust me, your JS-based crypto is also compromised.
Once it's at the server where it's secure from being tampered with, encrypt it. Anything else is a really long way to waste your time.
Also, go read these books:
![This one is free][4]
[![This one is cash money][5]][5]
(source: [schneier.com](https://www.schneier.com/images/book-ce-150w.jpg))
Then when you understand them come back and scream at me about why I'm wrong and don't understand how much you need JS on the client to do crypto.
There is an excellent DES (and by extension 3DES) implementation in JS, which I use quite often. I'll put up the link Monday, when I'm at the office and have it ready. Results from this (after base64 encoding for the transport) work perfectly with .Net/Mono (builtin), Java (bulitin) and PHP (mcrypt).
Found the links, but both are dead: http://www.shopable.co.uk/des.html and http://www.netdealing.com. I have put it up on http://pastebin.com/KbRsWKJY
This page has CTR mode, which is available in Java. I would recommend keys of 128 bits or you might run into trouble regarding the Java export policies on larger key sizes.
Here is a page which uses some very usefull methods of encryption, including password encryption techniques and ciphres with integrity checks and authentication, although you may need the bouncy castle libraries on Java to match those all.
There are oodles of libraries for JavaScript, but character encoding issues will be present on any of them. So make sure you use the same encoding both on the JavaScript side as well as on the Java side. A quick look up assures me that JavaScript uses UTF-16 internally, but don't hang me up on that.
Finally, don't try this at home, the libraries are there, use them (especially if they mention tests and/or official test vectors).
Like the other answers said, if you don't have to encrypt with JavaScript, avoid it. However, there are some valid use cases to encrypting in JavaScript.
When you need to, I recommend this library: https://keybase.io/triplesec/.
It's more secure than DES, which another answer links to.

Categories

Resources