Network enabled device with SSL?

Rabbit Semiconductor will release a core module with an 8-bit Rabbit processor next month that handles SSL very well without any extra hardware to accelerate encryption and decryption. Initial authentication takes 2-3 seconds, throughput is about 120K bits/s. A certificate creation utility is included.

The integrated HTTPS server will work with all major browsers without changing default security settings.

Maybe I'm reading this too literally, but normally when you issue your own certs the root is not trusted by browsers - this causes browsers to popup a warning when the server is accessed. Easily corrected within an enterprise, but not practical for public use.

Are you saying you've worked around this, and how? If not, are you planning to support certs from major issuers for public applications?

That's pretty impressive to squeeze a respectable SSL server into an

We certainly managed to put MD5 + 3DES onto a PIC18 a couple of years back, but we decided against full SSL - we reckoned it was better to move the security into the application protocol (including some challenge-response techniques to add proof against replays and tampering).

We also came up with a scheme for an "SSL Assistant" which is the subject of a patent application and I probably can't discuss here yet.

pete

-- snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Selfsigned certificates are the only doable way unless you want to spend big bucks. Either they trust your device or leave it.

Rene

The only feasible way to deal with the flaming ridiculousness of certicificates in web browsers is to self-sign the certificates. You could have a local (organizational) CA that signs them if you really want to play the PKI game, but now there's two certs embedded in the device and you're now managing a local CA.

I would imagine that if you've got a static IP address, and if you spend the bucks then you can happily get Verisign / Thawte to take your money and sign a cert for you. Import cert into Rabbit and enjoy the little 'key' icon in your web browser. This cert, of course, means nothing regarding the actual authentication of the device in question - it just ties an IP address to a name (valid credit card holder).

Alternately, assign a static IP address to your device, generate and sign your own cert, import into device, and let the user accept press 'enter' when the warning pops up. From then on, no warning. Enjoy little 'key' icon in your web browser.

If the decive can change IP addresses once in the field (user configuration, or DHCP), then you need some way to generate the cert on the device itself - not really a problem.

There's really no other way to give the user SSL on a device where the IP address is apt to change. Consider network devices (routers, managed switches, etc) - their IP devices are unknown when they leave the factory, and some users (think they) want SSL to connect to the box's management web server. The simple solution is generate a new self-signed cert whenever the management IP address changes.

Not DES let alone 3DES - see some earlier posts in this group. RSA key lengths weren't disclosed.

Kelly

You still have to go through a signing authority such as VeriSign for that.

The trick was in developing some new processor instructions that speed some of the arithmetic up:

RSA public-key encryption routines (includes PKCS encoding) Multi-precision arithmetic for RSA RC4 symmetric bulk cipher routines SHA-1 message digest MD5 message digest

NetBurner ,

We implented just what was needed for out-of-the-box compatibility with browsers for the first release. We'll see about DES if the demand is there.

The key length for initial public key exchange is 512 bits.

After that, 128 bit keys are used.