Applet Authentication

Discussion in 'Java' started by Roedy Green, Jan 8, 2006.

  1. Roedy Green

    Roedy Green Guest

    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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Jan 8, 2006
    #1
    1. Advertising

  2. Roedy Green

    Chris Smith Guest

    Roedy Green <> wrote:
    > 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
     
    Chris Smith, Jan 9, 2006
    #2
    1. Advertising

  3. Roedy Green

    Oliver Wong Guest

    "Roedy Green" <> wrote in
    message news:...
    >
    > 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
     
    Oliver Wong, Jan 11, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Love

    applet vs. canvas in applet

    Rob Love, Jul 7, 2003, in forum: Java
    Replies:
    1
    Views:
    640
    Liu, Chunyen
    Jul 7, 2003
  2. webster
    Replies:
    0
    Views:
    876
    webster
    Jul 20, 2003
  3. Andrew Thompson
    Replies:
    0
    Views:
    428
    Andrew Thompson
    Aug 5, 2003
  4. Blah Blah
    Replies:
    0
    Views:
    1,445
    Blah Blah
    Aug 13, 2003
  5. Jade
    Replies:
    3
    Views:
    942
    Roedy Green
    Aug 14, 2003
Loading...

Share This Page