Applet Authentication

[Roedy Green]

I think about this problem periodically and then throw my arms in the
air that it is impossible. Yet perhaps perfection is not needed, any
more than you don't need a perfect lock on your front door to deter
most thieves.

What I am looking for is a scheme for Applet Authentication -- I want
assurance nobody has tampered with the code that is talking to my
server. I don't mean validate the user, I mean validate the code.

You may say, don't sweat it, just validate messages at the server.
This is not enough. Why?

1. The Applets/JAWS apps might be playing a game where they interact
directly with other players. You want to prevent people from
cheating.

2. The Applets/JAWS apps might be doing a BitTorrent like download
where they must co-operate with each other. You want to prevent fake
Applets that take but don't give.

What possible tools come to mind?

1. jar signing. This seems to be designed only to protect the end
user. I know of no way for the server to find out if the code running
was signed by the appropriate party, even when the server knows the
private key. The problem here is the hacker has the legit code, so
can compute any checksum desired on demand.

2. snap inspection. The code downloads a byte array with a custom
classloader and runs the code and returns a response within a time
limit. Since the hacker has no advance knowledge of the code, it is
difficult for him to prepare. Even if he hands it to a legit copy to
compute, that legit copy likely won't have the expected internal
state. If the code fails inspection the userid/password/logon cert is
invalidated.

3. leave out some crucial modules and download the version of the day
each time. You change the protocol daily.

I wondered if anyone has some ideas, especially ones that could be
encapsulated and plopped into any app.

 

[Chris Smith]

I think about this problem periodically and then throw my arms in the
air that it is impossible.

It is indeed impossible, in the sense that it can't be solved in a
strongly cryptographically verifiable way, without running the sensitive
code on the server.

Your best idea is probably to change the code over time. Of course,
there's a trade-off between how many and how fundamental the changes you
make, and how difficult that makes it to maintain your own code. Every
single step you take to make maintenance easier (for example, moving a
cryptographic key to a resource instead of embedding it into multiple
steps spread throughout your source code) makes it easier to break.

You could join Microsoft and others' "trusted computing" initiative that
would make this truly possible, but then we remaining sane people would
have to shoot you.

I realize this isn't a good enough answer for everyone, but I'd just get
out of any business that required this of me.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

What I am looking for is a scheme for Applet Authentication -- I want
assurance nobody has tampered with the code that is talking to my
server. I don't mean validate the user, I mean validate the code.

You may say, don't sweat it, just validate messages at the server.
This is not enough. Why?
[...]

2. The Applets/JAWS apps might be doing a BitTorrent like download
where they must co-operate with each other. You want to prevent fake
Applets that take but don't give.

Like Chris said, I can't think of a simple yet secure solution to the
problem. I just wanted to point out in the case of BitTorrent, protection is
built into the protocol itself. Note how BitTorrent "works", even though the
protocol is completely open, and anyone is free to implement clients with
any behaviour they want.

Greatly simplified, clients do not give (or tend to give less) with
peers that don't give back. Of course, there has to be some initial "free
giving", or else people just starting to download (with zero bytes to share)
will never actually get anything. This is basically the Prisoner's Dilema
problem.

- Oliver