Skip to main content

Trusted clients in Java: possible?

6 replies [Last post]
denka
Offline
Joined: 2003-07-06
Points: 0

My question is not about whether a client should trust authenticity of a Java application, but rather a reverse problem:
- client is written in Java and is run on customer's computer
- client communicates with server, and it is the server who needs to know whether client's code is intact, since server accepts data that it can not easily (or at all) verify

From my discussions, many folks would plainly say it is not possible. But, without necessarily understanding too much about the possible combination or parts of it, I tend to still think that a combination of the following features should make it possible:
- Java classloader and concept of "sealed" JARs
- encryption
- authentication
Is that enough? If not, what would need to be added? Is this really an impossible task?

If Java platform itself is compromised, then I'd guess nothing would help. OK then, can Java runtime's authenticity be verified somehow too?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
i30817
Offline
Joined: 2006-05-02
Points: 0

No. I think that what you want requires some form of hardware DRM in any language, ie: a trusted platform that authenticates software. Why would you want to do that anyway? Just use the old adage : never trust the client. If you want a secure form of digital money there are systems that assure authenticity, non-repudiation, privacy and integrity, i think. Don't remember the algorithm names though.

denka
Offline
Joined: 2003-07-06
Points: 0

I doubt DRM per se, standing for "digital rights management" has anything to do with this problem. Although from the sound of what Protected Media Path implementation in Vista is (called to assist in DRM enforcement), it's possible that similar crossplatform solution could be helpful.

It's not about money, it's about online games (and not full-blown casino-style gambling, just casual stuff) and cheat prevention.

tarbo
Offline
Joined: 2006-12-18
Points: 0

DRM may not look like a useful comparison, but it is really similar to what you are trying to do. Where DRM tries to figure out whether your medium is acceptable, you are trying to ascertain whether your client is trustworthy (medium = client, DRM = server).

Short from using subatomic particles, any security system can be circumvented with varying degrees of effort. Identity can be copied/imposted, communications can be simulated, encryption can be cracked. So ultimately, someone is going to figure out how to cheat. But you can limit the effort/cheatability payoff.

A relatively easy way is to have the server send out a challenge to a connecting client. That challenge could be anything, from an n-bit hash of its data files to a private key (but how does the client know [i]you[/i] are trustworthy enough to handle a private key, eh?). If the client fails to provide a proper answer, it does not mean it is cheating, but that its state won't allow it to play on the server and that it should reinstall/update.

Typically, security rests not in a single system, but in a number of cumulative and interoperative systems. The hash challenge mentioned above isn't a way of establishing trust, it just entices the server to give you a shot.

Security is an entire field in and on itself. Google or Wikipedia around a little. But keep in mind that any sufficiently determined hacker can pretend to be a trustworthy client. What you [i]can[/i] do is set a bar on how determined said hacker must be.

denka
Offline
Joined: 2003-07-06
Points: 0

I'm looking for pure-Java solution. Not sure how Java can obtain a hash of files comprising the client, especially in restricted deployment scenarios (WebStart, Applets).

tarbo
Offline
Joined: 2006-12-18
Points: 0

If Java can't access the files it needs to run the client, then it can't well run the client, now can it? And if you can access the files, you can compute a hash over them. But this as an example.

In casu applets, you have the browser as your platform, so have the option to negotiate with the browser for security.

How about you give us the full picture rather than correct our guesses, hm? :) The less you give us, the more you have to figure out for yourself.

denka
Offline
Joined: 2003-07-06
Points: 0

There really is not much to add. Consider a game that is delivered as an applet, and the client application has the game logic and may report winnings to the server. But how can the server verify that the game is not a decompiled/hacked set of files that simply rakes up player's rank?

I've no clue how to "negotiate" client authenticity and integrity using a browser (especially since there's more than one). This is why I brought up JAR sealing. And you are correct in that sense that authenticity of Java platform, too, may come into question depending on implementation...

Have somebody user sealed JARs? What for and how exactly?