Not as much of a difference to CueCat as you might think. The firmware on the box is signed and locked, preventing you from customizing it. Their business model doesn't have any allowance for pricing that reflects the costs of providing a Fon service (which is an issue in those parts of the world that still have volume-based pricing or volume limits on services) and also doesn't guarantee that you'll see any money out of it anyway.
obDisclaimer: I wrote Charon with a mind to specifically dealing with these issues, so I may care about them more than anyone else does...
Nonsense. Bluetooth security is specifically designed with low-power, low-CPU devices in mind. It isn't "secure" as people understand things in the Internet world, and it isn't intended to be. The BT specification explicitly states that applications that care about security should layer their own on top of the BT connection layer.
You'd have exactly as much luck changing the encryption in a WiFi keyboard as you would in a BT one (ie, none whatsoever unless the manuacturers put in some buttons on the keyboard and driver support to do it), and your battery life would be reduced by two orders of magnitude or more.
I'm working on this particular problem - mostly 'coz I'm in Australia too:)
Charon will do micropayment-based charging for using a wireless service. If you can run on it on your wireless device (there's ipkgs available for OpenWRT at the moment) then you can share wireless on a cost-recovery (or profit-making, for that matter) basis. I have my iBurst service available to all and sundry at 4c/MB at the moment, for example.
Keymgr serves a particular role in a particular scenario. If you bounce around between multiple machines regularly, even if it's just with scp, agent forwarding is a beautiful thing. You can have key-only authentication throughout your network, and still minimize the exposure of the keys on disk.
Unfortunately, agent forwarding is also a can of worms. ssh-agent allows any hostile machine that you forward onto to use your keys to do arbitrary damage as long as you remain connected.
The first couple of good steps to take are mentioned above; interactive confirmation of forwarded authentication - which is possible with ssh - and using a physical token for added security.
I did once write a patch for gnupg to use keymgr for key management, but it was rather ugly and was treated to an (entirely deserved!) cold shoulder. It was very satisfying to sign and decrypt email with my Java ring, though:)
I've started working on libow again, and I'll probably move onto cleaning the rust off keymgr before my holidays are over - and maybe get around to writing that risk analysis/best common practice paper on ssh that I've been meaning to do since last century, instead of starting to braindump into a/. comment:P
Slashdot Mirror
Not as much of a difference to CueCat as you might think. The firmware on the box is signed and locked, preventing you from customizing it. Their business model doesn't have any allowance for pricing that reflects the costs of providing a Fon service (which is an issue in those parts of the world that still have volume-based pricing or volume limits on services) and also doesn't guarantee that you'll see any money out of it anyway.
obDisclaimer: I wrote Charon with a mind to specifically dealing with these issues, so I may care about them more than anyone else does...
Nonsense. Bluetooth security is specifically designed with low-power, low-CPU devices in mind. It isn't "secure" as people understand things in the Internet world, and it isn't intended to be. The BT specification explicitly states that applications that care about security should layer their own on top of the BT connection layer. You'd have exactly as much luck changing the encryption in a WiFi keyboard as you would in a BT one (ie, none whatsoever unless the manuacturers put in some buttons on the keyboard and driver support to do it), and your battery life would be reduced by two orders of magnitude or more.
I'm working on this particular problem - mostly 'coz I'm in Australia too :)
Charon will do micropayment-based charging for using a wireless service. If you can run on it on your wireless device (there's ipkgs available for OpenWRT at the moment) then you can share wireless on a cost-recovery (or profit-making, for that matter) basis. I have my iBurst service available to all and sundry at 4c/MB at the moment, for example.
Still early days for usability, though.
Keymgr serves a particular role in a particular scenario. If you bounce around between multiple machines regularly, even if it's just with scp, agent forwarding is a beautiful thing. You can have key-only authentication throughout your network, and still minimize the exposure of the keys on disk.
:)
/. comment :P
Unfortunately, agent forwarding is also a can of worms. ssh-agent allows any hostile machine that you forward onto to use your keys to do arbitrary damage as long as you remain connected.
The first couple of good steps to take are mentioned above; interactive confirmation of forwarded authentication - which is possible with ssh - and using a physical token for added security.
I did once write a patch for gnupg to use keymgr for key management, but it was rather ugly and was treated to an (entirely deserved!) cold shoulder. It was very satisfying to sign and decrypt email with my Java ring, though
I've started working on libow again, and I'll probably move onto cleaning the rust off keymgr before my holidays are over - and maybe get around to writing that risk analysis/best common practice paper on ssh that I've been meaning to do since last century, instead of starting to braindump into a