Note the basic "memory storage" iButtons may reply with constant data that can be "sniffed" and played pack. Things like the Java iButton can perform operations on the data. Say, you get a scenario like this: Have public keys exchanged between server and iButton, encryption algorithm implemented in both. iButton pressed to the reader issues a challenge request. Server issues the challenge: Generates a random number (of arbitrary length, say 2048 bit, or maybe some other quite unique data like somehow mangled epoch time), signs it with own private key and encrypts with iButton's public key, then sends it. Feel free to sniff, you don't know what number it was. iButton decrypts the data, checks signature (to see if it was the server and not the "man in the middle" trying to obtain as many replies as possible) then signs the number with its own private key and encrypts with server's public key. Send away and if the server recognises data arrived from a valid iButton and it was exactly the same number it had sent in the first place (or the same number modified in some known, predefined manner, i.e. multiplied by pi) the auth is granted.

Person snooping on the line may catch the challenge and response but since the number encrypted is unique, both the challenge and response will be unique to each session. Reading the line will prove useless.