Slashdot Mirror

http://www.ibutton.com/ - free samples available.
2.6.13 kernel has already some very decent support for it (.12 - sorry, not so decent...; .14-rc? seems even more promising, this is a very actively developed area) - now just wait for good userspace support software. It's in /sys already.

iButtons are way more rugged than USB stick (think surviving in pockets of Indiana Jones, Gordon Freeman and Lara Croft), smaller and more comfortable in use and some are designed to be unlockable only with a password ;) One problem is the biggest one is 8 kilobytes, so if you plan using them to store MP3s, sorry. But PGP keys, password lists etc - why not?
And if you're a Java freak, there's a java-based minicomputer in one of them :)

...for last 2 months or so, like for a salvation. I want to make that auth system using iButtons and .13 is the first to include full, useful system. (1-wire protocol was present in the kernels before, and in userspace even earlier, but only with .13 it's mature enough to be usable.)

One sollution would be the iButton

Add in the JINI family - and the lovely little TINI from DalSemi which I'm writing an embedded web server on (can't tell you what for, though sysadmins will love it when it ships). This thing runs a reasonable JVM with several serial, ethernet, etc on an 8051 (the thing they put in keyboards as microcontrollers)!

TINI

Its been around for a while.
Enjoy,

Just as an aside, I've seen another neat application of java smart cards in the form of buttons. At the high school I work at we have lockers for the terrorists...uhh...students to stash their books, drugs, guns, etc. Most of the lockers are your standard lockers with dialed combinations and a key for "administrative override". Each of those lockers has 5 combinations in them which is rotatable by the admin key.

Regardless. Some students here do not posess the mental or physical capability to work said dial lockers, or a keyed lock (sorta). So these have iButton readers in them, and the students have ibutton dongles. They, or their aide, presses dongle into locker reader, and the lock pops open. Students are happy, the aides are happy, and the ADA is happy.

Microsoft will get this technology deployed out to people who run 100% windows shops, sending companies comp samples for the various VP/C?O's to work with, and they will think it's the coolest thing since sliced bread. Business weekly will run a 3 page ad from microsoft on it, so all the little PHB's of the world can read it and insist that its better than the rest. Admins will be forced to use it because the regular old smart card tech will need some driver or whatever, while .NET enabled ones will work because of a critical security update pushed out.

Maybe I'm still just bitter about the GDI+ detection tool.

See this page:

http://www.ibutton.com/ibuttons/java.html

I've had one of these Java-powered iButtons since 2001. If you have the PKI in place it's a very easy technology to use. If you don't, it just gives you bragging rights in the my-computer-is-smaller wars.

Both good.

Phil

Microcontrollers:

• http://www.rabbitsemiconductor.com/ Rabbit
• http://www.basicmicro.com/ PICs
• http://www.ibutton.com/TINI/hardware/index.html TINI

RFID is evil in this way that it can be read anytime by anyone without the person carrying it ever knowing. It's also very vulnerable to EMP, quite easy to damage, jam, fake...

Why not something that is just as simple but requires simplest of actions from the owner. iButton. Just touch the small metal can (immune to mostly all "environmental challenges") to a reader, and the contents are being read. Or a Java program (embedded in the chip non-virtual java machine,) is being executed. Or the data will be accessed only after answering to a proper cryptographich challenge Or, or... So if you want to pass through the customs, just touch the iButton with a jpeg of your face to the reader. If somebody wants to steal data from your iButton, they must mug you or trick you into placing your iButton against their reader (and providing proper passphrase which normally sits in governmental database)

Embedded rules for these kind of applications. If you want to have a really custom solution, the One-wire products are more interesting. Start with TINI (a "Java Stamp" with ethernet) and add One-wire sensors and controllers.

Java is a nice choice for embedded platforms. It runs several times faster than on PCs (it's native for the hardware, not "emulated" through JRE), the hardware is inexpensive and can perform really sophisticated jobs. I think it may be one of major reasons for Java to take up so much.

Java powered cryptographic iButton - a chip the size of your hand watch battery (stainless steel, shock-resistant, water-resistant and several other-resistant "iButton" package) with Java support.

That's cool. price is $53.21 for the most recent version, $34.22 for the older model. Do you know what RSA key size they use? Also, my inate tin-foil-hat suspicion makes me wonder if there's any way to set my own key so it's not the one pre-set by the factory (who knows if they keep copies of the keys of all the products they sell...). Also, it would be good to know what the private key is, so I can keep it in a safe place in case I lose the device.

I wonder how long until my passport and drivers license is replaced by one of these...

-jim

Actually yes, Dallas semiconductors have been making it for years now. Have a look at their line of iButtons. They can even be fitted to a ring, or you can attach it to your wristwatch, or just use a keyfob.

Use it to sign onto windows, access control and whatever you think of.

I played around a little with a few cheap unique-id-only ibuttons and they are quite cool.

I would use the crypto ibutton as an authentication scheme, possibl storing the password.

Anyone who frequents Laser Quest (a laser tag arena) knows that they use Maxim/Dallas Semiconductor iButton devices to activate the "blaster" with your callsign and to keep track of statistics. The problem with this is that anybody with a knowledge of microcontrollers and some basic hardware skills (such as, ahem... moi) can rig up a simple unit to read and write to them (using a serial protocol called 1Wire). While this might not seem particularly relevant to the topic, it demonstrates the same concept, which is that if you make widespread use of a low-cost technology that nerds have free access to, it's only a matter of time until one of them starts to get curious. And then you're screwed. ;)

Paper trails are not needed to secure voting. They are expensive and slow things down. What is needed is a system where anybody can easily count the votes, and anybody can easily verify their own vote.

This system must, however, insure voter anonymity.

So here is the solution. Everybody has a private cryptographic key. When they vote they encrypt their vote with their key, possibly using something like a Java Ring or iButton or maybe a smart card, and the system records the pair ( encrypted vote, unencrypted vote ). The important thing is that the private key must be kept secure and secret even when interfacing with a malicious sever, terminal, etc. Finally, everybody has access to the entire voter database via the internet.

Independently, anybody could download the entire database and count the vote... verifying the government's count.

Similarly, anybody could verify that their vote was recorded correctly by checking that their pair ( encrypted vote, unencrypted vote ) is in the database.

Giving up a little anonymity, but still keeping a person's choice secret would allow further system integrity. The database could store the identity of all registered voters along with the elections they voted in. This data could be used to verify that the total vote database does not contain more votes than the number submitted by valid registered voters.

Of course it would be up to the people to verify that the system accurately recorded:
1. their registration status
2. whether or not they voted in the election
3. their actual vote (as described above)

The system could never lie because it would never know who is requesting the data. Individual counties, companies, organizations, and individuals would be able to download all or part of the database. These independent organizations could verify the integrity of the data. An individual person could verify the data directly or indirectly through one of these organizations.

Hence the importance of the entire database being freely accessible. The system could even be distributed in the sense of distributed databases or distributed operating systems... so as to further insure reliability, scalability, integrity, etc.

Something like a timed ticket+ibuttons would work.
Doctor arrives at work, logs in his user/password then simply taps his ibutton on whatever system he wants to use. Hit's the logout button when he's done, and moves on to the next machine.

Why do the login/pass thing in the morning? Because people lose small things like ibuttons. So each morning when you login (and for the next 8 hours or however long until the login ticket expires) the ibutton supplies is the new "key". If you lose it, simply get a new one and login again.

ibutton url

In this case it must have been a little more than adding ".. with a computer" to the end of it. :^) I thought Dallas Semiconductor had done stuff like this with their iButton single wire gizmos, but I don't see any mention of using the body as the single wire.

Maybe it was a TINI?
You can order them direct from Dallas Semiconductors or, if you live in Europe, it might be better to get one from Taylec

So, how is NFC any different from Dallas Semiconductor's iButton which has been around for years and is a proven technology?

Chip H.

Quite some time ago, a slashdotted mentioned this as having worked for him. I've yet to actually starting playing with mine (though I do have one), but I plan to basically have an apps which scans for the presence of a button (maybe upon a certain key being held) and grants access if the unique ID on the ibutton matches the one in records.

Anyone ever played with ibuttons or similar items for this purpose?

The IButton also uses "touch" to transfer digital credentials and other information to nearby devices. It uses plain, old-fashioned serial communications technolgy.

This "Magic Touch" technology simply sounds like a more complex way of achieving the same thing.

I can only hope this alliance will take security as seriously as the IButton folks have.

It uses a 8051-variant of Dallas Semiconductor and NASA did buy it from eBay!!! (anybody remembers 8086?)

can it be or can't it be?

open4free

Think how great would it be to only need one device to communicate, start your car, and pay for whatever you need when you go out.

it exists, it's called an ibutton

and can do everything you say. in fact my harley starts with it, I can unlock my doors to my home with it.. and it can act as a creditcard/debitcard/micropayment device. plus it's 10 times more secure than any creditcard,key,smartcard. and much more durable and can be worn as a ring (as I have mine.)

the thing holding it back is adoption. NOBODY want's to give up their "custom" control they have for their service.

if you make a system open enough for multiple uses, then company Z loses complete control over something..

There are a lot of advantages to this but there are two huges ones I can think of. A full TCP/IP stack included for absolutely free. (Since it implements the java.net package) This makes it veryyy easy to net-enable various devices. Another big advantage is that you can develop most of the firmware on your desktop and move it to the embedded device when it's ready.

I don't know about the shipping to Canada part, but try this www.ibutton.com as a source.

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

That's not true. Check out The TINI.
You can also program it in 8051 assembly, AND with the 1-wire interface you can hook a buttload of different sensors and things to it.

If you *really* want a JRE (which is generally not synonymous with performance, in the microcontroller world), check out the TINI from Dallas Semiconductor, here.

If you want to get into heavier duty gear (and available only in surface mount), you can look at things like the Patriot from PTSC, here. There are also several others that I've seen, but can't recall the name of. A little Googling should find those.

And to make it even better the whole setup is controlled by none other than linux.

As a Windows user (yes, there are still a few of us around) I don't find that better.

In any case, he's obviously a hardware guy and not a software guy. The program has to run as root, it's controlled through the printer port, and he is puzzled how to make it work through the printer port using Windows. It would have been cooler had he used something like TINI to allow control through a network. "TINI's networking capability extends the connectivity of any attached device by allowing interaction with remote systems and users through standard network applications such as Web browsers."

I have been playing with TINI from Dallas Semiconductor. It runs java code, and supports a pretty good subset of the full Java 1.4 spec. It costs around $100 to get started with it.

Twostep

If you used something like the dalas-semi one-wire i button stuff, (see here) i bet you could do just that...

This is silly. They should be using iButtons. Totally waterproof & nearly indestructible. About the size of a thick dime, can be made into jewelery, etc. The Java versions are only slightly larger and can hold public & private keys and perform detailed transactions.

And they're cheap! Less than a buck each in bulk. A little more spendy for the Java iButtons. They aren't contactless. They automatically transfer data at 140 some odd Kb/s when you tap them onto a reader. One quick tap is enough to complete the transaction.

I've bought some and am having one built into a ring to use for access control for my home (unlock doors, etc) so I don't have to carry keys anymore.

I have no idea why Visa/etc haven't signed on to this idea. iButtons are the best thing since sliced bread.

I have a Java iButton, and the focus of the SDK is on its cryptographic capabilities. If you're looking for something general-purpose with that feature, it would be the one.

Afaik, the Segway uses a version of the iButton which stores a small amount of other data in addition to the serial number. So, what the Segway probably does is check that the serial number matches what it expects, and also reads the data in the iButton to determine things like the maximum speed it's allowed to go. IIRC, at least one of the Segway keys is speed-limited, for "valet parking" etc.

So, to hotwire a Segway electronically (as opposed to somehow bypassing the electronic circuitry, if that's possible), you need to at least (a) determine what iButton serial number your Segway expects (hmm - wonder if it's printed on the Segway somewhere?) and (b) build a small iButton simulator which generates the required signal, using the documented OneWire protocol. However, you'd need to do some additional work to simulate the data storage on the iButton. You'd probably need to reverse engineer an existing Segway iButton key for that part - which should be easy, if you have access to a key.

Bottom line: hotwiring a Segway would take some work, and it would be tough without access to a Segway key to play with, but once you'd done one, it might be pretty easy to do the next one. A big question is how easy it would be to determine the serial number it expects, if you don't have the key. That could be a real barrier.

BTW, if you want a much more secure authentication mechanism, the Java version of the iButton will do public/private key encryption on the button, so it can be sent a challenge encrypted with your public key, and it will decrypt it with your private key and send it back to the challenger. Now that should be hard to hack.

Maybe you can use iButtons? They're more robust than plastic cards and you can add a keypad for extra security. You can also hook them up to a pc to keep a log. However, the buttons are quite expensive so let the students/staff pay for them or they'll lose them frequently..

A previous poster mentioned the MUSCLE project. It provides lots of open-source software for talking to smartcards, primarily for cryptographic applications.

MUSCLE works with JavaCards . With these it is relateively easy to write your own applets that run on the card and do whatever you want.

Lots of vendors supply JavaCard-compliant cards. For example, SchlumbergerSema, iButton, and Gemplus.

I always thought the idea of using a iButton ring was rather elegant, since people wear jewelry anyway. I guest the cost factor is too high for each unit though, so it's never caught on. Too bad since some of them Java, and can act as a self contained wallet.

Now for you, the Java Ring might be just what you're after. Sold by MRI, you can get ones that store, encrypt or compute. It's FIPS-140-1 certified, 134K of SRAM, zeroizes on tampering. Here is the fact sheet.

Of course, you can get a nice plain wedding band, and ask her to get you the Java Ring for the other hand. Your call.

I rather like these: a SIM-sized micro-controller running Java (hence capable of acting as a Web server). There is an ethernet pinout, but the easiest way to play with them^W^W^Wprototype is to put them on a daughterboard. You can telnet into them and download code by FTP. The bare microcontroller costs £40 ($50) for the 512kb version.

Does the key have a serial number? If so, you may launch a script that authenticates off that as well.
Of course, usb keys are for storage. There is hardware designed for what you want to do.

In particular, this looks like it might be an ideal solution.

The IButton did this more than 3 years ago. Just touch the ring to the blue dot.
And my sunblade just needs me to swipe a card. This is a method that leaves itself open to bigger hacks than the others... listening to the wireless protocol, copying it, and logging in as someone else.

Obviously, you should get her a Java Ring. They just released a new version that not only incorporates a Java Virtual Machine, but has 134 KB of space for downloaded programs. If she still wants a diamond, simply point out that a diamond can't do an RSA calculation in under one second.

titanium wedding rings are pretty nifty. it'd be cool to find ones made out of other out-of-the-ordinary materials. maybe get one of those iButton deals as the ring, so your s.o. can access your futuristic house without keys. it's the ultimate sign of your love, that you give them access to the inner sanctum.

I would think you could do the same thing with a tini board. They are not that expensive, the top of the line tini is $69, and come with a tcp/ip stack and are much smaller than the dreamcast, the board itself is no larger than a simm memory card.

Tini home page

It wouldn't be the fastest thing in the world but with such a small size you could put it inside of something that should be there, like a network hub, print server, etc.

Software for it is written in Java and converted to run on the Tini, but I believe there is also a way to use machine code too.

Chris (krafter@zilla.net)

Take a look at the Dallas Semiconductor TINI. It's a Java runtime environment on a 72-pin SIMM, complete with ethernet, serial, I2C, parallel IO, battery up to 1 meg of NVRAM, filesystem emulated in RAM, etc, etc. You can write web or ftp services for it in a few lines of Java, thanks to the supplied classes. You develop your Java code on your PC, compile it to Java bytecode, and then FTP it up to the little TINI device. My description is not doing this hardware justice, so I'll leave some links below.

Anyways, my point is this type of device is probably easier to program than a Linux Dreamcast. It may or may not be cheaper (sub-$100). And it's a lot easier to hide, if that's the goal. I've programmed a handful of hobby projects with this board, and it's really quite amazing for the price. (Compared to trying to implement an TCP/IP stack on a PIC microcontroller, say.)

TINI hardware
TINI
TINI board resource center
more resources
DalSemi discussions

Take a look at the Dallas Semiconductor TINI. It's a Java runtime environment on a 72-pin SIMM, complete with ethernet, serial, I2C, parallel IO, battery up to 1 meg of NVRAM, filesystem emulated in RAM, etc, etc. You can write web or ftp services for it in a few lines of Java, thanks to the supplied classes. You develop your Java code on your PC, compile it to Java bytecode, and then FTP it up to the little TINI device. My description is not doing this hardware justice, so I'll leave some links below.

Anyways, my point is this type of device is probably easier to program than a Linux Dreamcast. It may or may not be cheaper (sub-$100). And it's a lot easier to hide, if that's the goal. I've programmed a handful of hobby projects with this board, and it's really quite amazing for the price. (Compared to trying to implement an TCP/IP stack on a PIC microcontroller, say.)

TINI hardware
TINI
TINI board resource center
more resources
DalSemi discussions

Hey, they could use TINIs.

Thus, the Dallas SemiconductorSecret Decoder Ring does require a two-contact connection. It would be more convenient if you could just touch metal to metal and go, for door locks and such. There's a round, socket-like arrangement instead.

Except for the deceptive name, it's a good technology.