GeeCON Prague 2014*
The moose likes Security and the fly likes I'm not a hacker, but.... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Security
Bookmark "I Watch "I New topic
Author

I'm not a hacker, but....

scott irwin
Ranch Hand

Joined: Aug 07, 2000
Posts: 87
I need to secure both code and files in the hands of consumers/hackers. I'm having trouble understanding where people put their encryption keys to keep them safe, or maybe they aren't safe (a hacker should know.)
What I want is a scenario where only the signed jar class can access the keystore provided in the same jar file, without a password. The fact that the code source is from the same signer, that is enough. Because I must provide a password to access the key, it provides a hole for hackers.
I wanted to encrypt my class file(s) so they could not be regenerated and supply my own classloader, but I'm back to the same problem with a password exposed in the classloader which can't be encrypted.
I don't see how to get around decompiling, recompiling with debugging and poking around to find the password. I've never tried, but it doesn't sound that hard given that security checks must occur early on in the code. Even with obfuscation, the password/key must materialize early on.
Even if I used JavaCard technology, a secure RMI connection to the reader requires access to some key. I could use an unsecure connection and have the card perform all encryption/signing, but I'm assuming that is sloooooow. Also, that doesn't protect my code. I could just hack the code and tell the card to sign anything I want.
It appears to me, you can only limit your loses in Java. The supported security models require trust at some level (i.e., don't give away the password, decompile my code) in the hands of either the user or device (i.e., card reader). But what if both code and device are in the hands of a hacker? Is Java wide open in that case?
Also, the whole signed/sealed jar thing....Can't I just decompile everything, recompile and execute from my new unsigned/unsealed jar with any "enhancements" I want?
I haven't tried to hack, but it looks like JODE, a good debugger, some time and I'm set.
Thanks,
Scott
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
You lost me, I don't get what you're doing.
What not start from discussing what you need to do, as opposed to how you want to do it? That is, say things like "multiple users will access the computer, anyone may access the code, but only valid users can run it."
As for decompiling, you can never prevent that. You can obfuscate the code, making it harder to follow what's going on (all the classes, fields, and methods have names like "a", "aa", etc).
--Mark
scott irwin
Ranch Hand

Joined: Aug 07, 2000
Posts: 87
Mark,
What I need is a trusted computing platform for java. Given that is a JSR underway, what is the best I can do at the present?
Ultimately, I'm looking at the J2ME(2.0) environment but I might be forced to fall back to the J2SE environment. I'd have to split my code so that some executes in the VM and some executes in a javacard/smartcard. In the J2ME environment, I'd be looking at proprietary extensions to the VM to access the smartcard (I assume.) Anybody done this?
I guess my root question is: How do you secure encryption keys for the security of the application itself? Given today's environment, the only way I can see is to use JavaCard technology and let it perform all of the encryption/decryption/signing functions.
Obfuscating the code to hide a symmetric key or keystore password will slow down the determined attacker. It's still too easy to find the code working with the java security packages as those names remain unchanged. Then watch the byte[] or Strings in those classes.
Thanks,
Scott
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by scott irwin:
What I need is a trusted computing platform for java.

Let's back up. Why? What exactly are the system requirements?
Originally posted by scott irwin:

Obfuscating the code to hide a symmetric key or keystore password will slow down the determined attacker. It's still too easy to find the code working with the java security packages as those names remain unchanged. Then watch the byte[] or Strings in those classes.

Very true. For this reason, as well as others, you never put keys/passwords/tokens directly in your code.
Originally posted by scott irwin:

I guess my root question is: How do you secure encryption keys for the security of the application itself? Given today's environment, the only way I can see is to use JavaCard technology and let it perform all of the encryption/decryption/signing functions.

Let me put it to you this way, how do you store a key inside a house, when you're worried about strangers coming in and searching the house? Answer: you get a safe/lockbox. You created a small zone inside the house that requires secondary access. If you put the password in something you give to people, you will give them the password.
How do computer systems solve this? When I log in to my laptop, it asks for a password, but obviously the laptop must know the password so it can verify it. It does this by "locking" the password file. In Unix, for example, passwords aren't stored as plain text, but rather, each password is hashed. If someone looks at the file, they only see the hashed file. When I log in, my password is hashed and compared against the hashed version in the password file. If they match, I must have typed in the correct password.
Windows system store keys directly on the system as well. In this case, the keys are encrypted using a password (or physical token like a smart card or thumbprint). Again, the password itself is stored in a "locked" way.
--Mark
scott irwin
Ranch Hand

Joined: Aug 07, 2000
Posts: 87
Mark,
Let's say I'm Visa (and I'm not) and I want to maintain a balance on a consumer's device. The code that manipulates the balance must be secure as well as the balance file. The application I (or Visa) distributes needs to send/receive encrypted/signed messages to it's back-end system.
So Visa has it's own key that must be stored on the device to encrypt/sign messages/files. I need to know that only my valid code executed the payment/adjustment. Any code that could obtain my key could sign fraudulent messages.
So short of Javacard/Smartcards (unless I can use Javacard from J2ME via proprietary provider extensions???), is there any method/pattern to secure my key in the hands of a hacker? In your password example, if you know the password (i.e., it's your password that protects my key), you can get the key from the keystore and sign anything you want.
I'm still in a prototype stage, so the best solution given the current limitations will do. But I think the next killer app is being held up by the lack of a trusted computing platform. Many companies are working to crack that nut, and if Java wants to play in that wave of killer apps it too must be secure. I hope JSR-177 nails it.
Thanks again,
Scott
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Visa's private key must not leave the Visa building unless it's well-protected by hardware.
It does not belong on a consumer's PDA.
Here's the first thing that comes to my mind:
Generate a key pair for each customer (on their own computers) and encrypt it locally using a symmetric cypher PGP-style. Strongly recommend that customers keep their key safe and tell them that if they lose it you can issue a new one, but any data encrypted for the old one will be lost.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by scott irwin:
Let's say I'm Visa (and I'm not) and I want to maintain a balance on a consumer's device. The code that manipulates the balance must be secure as well as the balance file. The application I (or Visa) distributes needs to send/receive encrypted/signed messages to it's back-end system.

Let's bakc up even further. Why would Visa want to do this? Visa maintains all balances locally (your account info is in their database). The code that maniuplates that information is also on their servers. The best you can do is run software which requests that their local software modify your account. They trust their software.
Their software executes when:
1) Someone locally invokes it
2) Someone remote, who has proven themselves as able to asks it to run (i.e. a verified customer) on their behalf
In the latter case, this is either done programmatically, or by using a call center, where the operator is trusted to verify your identity, and the operators software is trusted to invoke the operations faithfully.
Bottom line, most "account software" never let the user maniuplate the account directly with the software they are given, for the reasons you are encountering.
--Mark
scott irwin
Ranch Hand

Joined: Aug 07, 2000
Posts: 87
Mark,
Like I said, I'm not Visa and my project is not a credit/debit card, but I work in a group that's looking out > 18 months. I'm interested in leveraging the computing power in everybody's hand vs. routing information back to huge systems (edge computing.)
This led me to the whole trusted computing platform work that is being worked on by various companies and organizations. In taking my prototype to the next level, I needed to address security. I wanted to continue using Java but realized that the Java security model is there solely to protect the consumer from bad code and not bad consumers from my code.
So now I'm reading up on JavaCard to perform all of my security functions. Basically splitting my application between secure and unsecure functions. I agree with David, the key never leaves the secure platform (smartcard). I think this will lead me to a secure edge computing environment.
Scott
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by scott irwin:
Like I said, I'm not Visa and my project is not a credit/debit card, but I work in a group that's looking out > 18 months. I'm interested in leveraging the computing power in everybody's hand vs. routing information back to huge systems (edge computing.)
This led me to the whole trusted computing platform work that is being worked on by various companies and organizations. In taking my prototype to the next level, I needed to address security. I wanted to continue using Java but realized that the Java security model is there solely to protect the consumer from bad code and not bad consumers from my code.

First, understand that the Java security model solves the OPPOSITE problem. Namely, how do I, Joe User, know to trust software from the Big Corporation. Java said, you can trust it, because our security model will make sure it doesn't do anything you don't want it to do, e.g. deleting your files.
You posed the opposite problem, how do we at the Big Corporation, trust the answers from code running on Joe Users computer, given the Joe may have modified the code.

I asked you to back up, because we need to look at the basic trust model: who do you trust, and what do you trust them to do?
You generally cannot trust code on someone else's machine to be unmolested. To give you an example, imagine I gave you an electronic draft of my book. How do I know you didn't modify it? I can ask you to give it back to me and run a checksum, but so what, you could've made a second copy and modified that. Now if you modified a draft, so what? But now let's suppose I gave you that draft for a reason. Now I'm going to start asking you questions, like tell me the third word on page 87. Now I need to make sure the integrity of the file is secure. That's not easy!
My guess is you need some type of hardware/OS support for this.
Can smart cards help? Well, a smart card can be used in one of two ways. First, it can be used as a token. A token is something to identify you. It's commonly an ID (drivers license), key (front door), knowledge (password, encryption key), unique trait (fingerprint).
Second, a smart card can be used to run "secure code." In this case, it's a kind of lock box, given out by the company. They trust that you can't tamper with it. For the record, none are truly tamper proof (reading, modification, loss, destruction, duplication), it's just a question of how much does it cost to tamper with it. This type of smart card works as follows:
1) Inserted
2) Identifies itself to the computer
3) Gets information from the computer
4) Maniuplates the information
5) Returns information to the computer
6) Is removed
It sounds like this is what you want.
--Mark
 
GeeCON Prague 2014
 
subject: I'm not a hacker, but....