X.509 certificates on small micros?

I did some Googling but didn't find a good source of info amongst the noise= - I have an application where I'd like to verify X.509 certificates. The a= pplication is something like SSL - basically I want to verify the legitimac= y of a certificate on a device before I allow it to interact with the syste= m, and conversely I want the device itself to verify the system's certifica= te. These applications are currently using 8-bit micros (say 8MHz AVR for i= nstance).

Any good references on flash/RAM footprint for this sort of thing, and exec= ution time on an 8-bit micro?

How about a low-end ARM7/Cortex-M3?

Thanks.

Reply to
larwe
Loading thread data ...

se - I have an application where I'd like to verify X.509 certificates. The= application is something like SSL - basically I want to verify the legitim= acy of a certificate on a device before I allow it to interact with the sys= tem, and conversely I want the device itself to verify the system's certifi= cate. These applications are currently using 8-bit micros (say 8MHz AVR for= instance).

ecution time on an 8-bit micro?

I have a customer asking for 16MHz 32K Flash 1K Ram USB digital keys.

formatting link

No sure if they really need all that, but not much more expensive than

8k or 16K anyway.
Reply to
linnix

oise - I have an application where I'd like to verify X.509 certificates. T= he application is something like SSL - basically I want to verify the legit= imacy of a certificate on a device before I allow it to interact with the s= ystem, and conversely I want the device itself to verify the system's certi= ficate. These applications are currently using 8-bit micros (say 8MHz AVR f= or instance).

execution time on an 8-bit micro?

PS: I have excess inventories and will donate them for good use. Please post your idea here.

Reply to
linnix

I cannot use excess inventory - I need generic information about doability = in 8 bits, footprint, etc. I know Rabbit's boards have SSL support in some = cases, but they have hardware assistance.

Basically the idea is to use certificates issued by myself as root CA to va= lidate whether system A is permitted to talk to system B and, on the other = side, if system B should listen to anything system A has to say. (Those two= paths are separate and might be blocked or allowed separately).

In short, assume system A is trusted, and unknown system B is connected. Sy= stem A sends random salt to system B. System B returns a UUID, some other d= ata, and A's salt, hashed and signed with System B's private key. System A = has access to a CA database (me) of UUID spans and their associated public = keys. It verifies the signature using the public key from the database. If = the check fails, System B isn't allowed to talk.

Reply to
larwe

No even for free? I got 25 8MHz 16K (At90usb162) boards before the customer changed his mind to 16MHz 32K (Atmega32u2). So, he is paying but not taking delivery. I'll give them out to anyone with a good design use.

He must have good reasons to dump 25 good USB AVR boards.

ware assistance.

He is doing all software authentications.

validate whether system A is permitted to talk to system B and, on the othe= r side, if system B should listen to anything system A has to say. (Those t= wo paths are separate and might be blocked or allowed separately).

Very similar, in his case, system A is his PC and system B is an internet server.

System A sends random salt to system B. System B returns a UUID, some other= data, and A's salt, hashed and signed with System B's private key. System = A has access to a CA database (me) of UUID spans and their associated publi= c keys. It verifies the signature using the public key from the database. I= f the check fails, System B isn't allowed to talk.

No problem. Communications are very fast with USB, so 1K key exchanges are not an issue. Most of the processings are done by the

16MHz AVR.
Reply to
linnix

No. I am doing the pre-analysis for an actual production device, or rather = a family of devices. These would be mass-produced in consumer quantities. I= have to scope how much burden it would add to some "small" peripherals (cu= rrently 8-bit but could be migrated to a cheap 32-bit). I assume it is no p= roblem on a big 600-700MHz ARM, of course.

You should post here, students would snap them up :) I myself have faaaaaar= too many EVBs I will never use... I could not in good conscience take any = of your offered boards, because they will sit in a box for almost certain.

Right now I am cleaning some 1500-year-old Roman coins, it involves soaking= in olive oil for about 6 months and brushing/replacing the oil once a week= . If I took your boards, then 1500 years from now some archaeologist would = be doing the same thing to them...

This is the part about which I'm curious. What is the RAM, flash and execut= ion time footprint of a 1K or 2K PKI key verification? SHA5 validation?

Reply to
larwe

r a family of devices. These would be mass-produced in consumer quantities.= I have to scope how much burden it would add to some "small" peripherals (= currently 8-bit but could be migrated to a cheap 32-bit). I assume it is no= problem on a big 600-700MHz ARM, of course.

Yes, I have many students (customers) snapping them up for Jail- breaking PS3 already. But I want to see some other real uses. I would certainly supply the hardware for open source X.509 studies.

ution time footprint of a 1K or 2K PKI key verification? SHA5 validation?

1024 bits (128 bytes) keys should not be a problem, even if MD5 needs more space. The 1K RAM should handle several set of keys. RAM is the only issue with AVR. Flash and Speed are not problems. I think he could do the X.509 with 512 bytes RAM, but need more RAM for other uses.
Reply to
linnix

y in 8 bits, footprint, etc. I know Rabbit's boards have SSL support in som= e cases, but they have hardware assistance.

validate whether system A is permitted to talk to system B and, on the othe= r side, if system B should listen to anything system A has to say. (Those t= wo paths are separate and might be blocked or allowed separately).

System A sends random salt to system B. System B returns a UUID, some other= data, and A's salt, hashed and signed with System B's private key. System = A has access to a CA database (me) of UUID spans and their associated publi= c keys. It verifies the signature using the public key from the database. I= f the check fails, System B isn't allowed to talk.

hi larwe,

I could try and give you some ballpark figures in regards to performance if we're talkng about RSA operations on X509 certs. However, I'm not familiar with 8-bit AVRs, I've worked with Z80-based uC and a range of ARMs (ARM7 and ARM9). But - I'm not quite getting the idea I'm afraid - in the description above is the "8-bitter" on the System A or System B? In other words, on "8-bitter" are you going to perform the private key or the public key RSA operation? Sorry for not reading all this carefully enough - I'm actually at work at the moment.

Reply to
tum_

That's fine - I'd just like an order of magnitude sort of idea of footprint= and execution time (on both platforms if possible).

The answer to this is "yes". In short, various Systems A and B already exis= t today, and they're currently 8-bit (mostly). I want to introduce this new= certificate infrastructure, and will tinker with the "who does what" quest= ion to minimize the number of devices that need massive hardware upgrades. = If it turns out we need to move to tiny ARMs on everything, that is doable,= though - a small Cortex-M3 can be had for around $0.80 these days...

Reply to
larwe

nt and execution time (on both platforms if possible).

ist today, and they're currently 8-bit (mostly). I want to introduce this n= ew certificate infrastructure, and will tinker with the "who does what" que= stion to minimize the number of devices that need massive hardware upgrades= . If it turns out we need to move to tiny ARMs on everything, that is doabl= e, though - a small Cortex-M3 can be had for around $0.80 these days...

This might not be a problem for you, but for my customer. USB Cortex- M* still can't beat AVR in price.

Reply to
linnix

rint and execution time (on both platforms if possible).

exist today, and they're currently 8-bit (mostly). I want to introduce this= new certificate infrastructure, and will tinker with the "who does what" q= uestion to minimize the number of devices that need massive hardware upgrad= es. If it turns out we need to move to tiny ARMs on everything, that is doa= ble, though - a small Cortex-M3 can be had for around $0.80 these days...

Low-end AVR, to be exact.

There are also deployment issues. To ensure that no two keys are the same, the firmware is compiled online and downloaded to the device by distributors (usually, more sophisticated users). All the data are also tracked and logged into a central database, with a gLAMP server. We did it with AVR, but haven't done it with M0/M3, since gcc-arm is not mature enough.

gLAMP: gnu Linux Apache MySQL PHP

Reply to
linnix

Well, I have no use for USB in this application... so that's OK :)

Reply to
larwe

-

But you would need a easy way to compile/download the firmware. Each firmware is likely to be unique and cannot be mass programmed. The local certificate needs to be stored in Flash or EEProm. But ARM does not have EEProm, so we are avoiding the AVR EEProm as well.

The key/certificate should be removable.

I think we went through many of the same discussions you are having.

Reply to
linnix

nt and execution time (on both platforms if possible).

ist today, and they're currently 8-bit (mostly). I want to introduce this n= ew certificate >infrastructure, and will tinker with the "who does what" qu= estion to minimize the number of devices that need massive hardware upgrade= s. If it turns out we need to >move to tiny ARMs on everything, that is doa= ble, though - a small Cortex-M3 can be had for around $0.80 these days...

Hmm, I don't understand the 'yes' answer to 'this OR that?' question, sorry ;) Anyway, I'm leaving the office now and don't have much time. Nor do I have any ready numbers at hand, especially about the footprint (as this has never been an issue for the devices I worked with, the performance was).

Briefly -

  1. 'private key RSA on an 8-bitter' - forget about it, unless you are OK to use really short keys (insecure).
  2. What key lengths are you realistically ready to accept (I mean what is the minimum key length you'd put up with)?
  3. On a second thought - please correct me if I'm wrong but my understanding is that you're not planning to involve any hardware crypto-accelerators, all the maths is to be done by the CPU itself?
  4. Any specific time constraints for, say, the private key RSA? Will you put up with 1 second, 5 seconds, 20 seconds, etc?
  5. 8Mhz 8-bit AVR you mentioned - does this CPU have hardware multiplication instruction?

To give you an idea: ARM7TDMI @ 66MHz, no Cache, fairly slow external memory, 2048bit key, private key RSA, highly optimized code using CRT =3D> 1.2 seconds, for 1024bit key =3D> ~200ms.

Reply to
tum_

Apologies, correction:

private key RSA, highly optimized code using CRT

Reply to
tum_

rint and execution time (on both platforms if possible).

,
c

exist today, and they're currently 8-bit (mostly). I want to introduce this= new certificate >infrastructure, and will tinker with the "who does what" = question to minimize the number of devices that need massive hardware upgra= des. If it turns out we need to >move to tiny ARMs on everything, that is d= oable, though - a small Cortex-M3 can be had for around $0.80 these days...

Yes, mul, muls and mulsu two 8-bit registers.

1024bit key should be around 1 second for 16MHz AVR.
Reply to
linnix

Better than Z80, then. It does not have MULs at all.

Public key (with short exponent) - probably. Private key - no way ;)

Reply to
tum_

,
c

exist today, and they're currently 8-bit (mostly). I want to introduce this= new certificate >infrastructure, and will tinker with the "who does what" = question to minimize the number of devices that need massive hardware upgra= des. If it turns out we need to >move to tiny ARMs on everything, that is d= oable, though - a small Cortex-M3 can be had for around $0.80 these days...

Can't say for sure for the OP, but probably very similar to us. System A is a 8 bit device and System B is a 64/128/whatever bits server. The 8 bitter authenticates against the server key. (don't want to say public key here).

Reply to
linnix

-

Yes, public key by the 16MIPS (single cycle) 8-bit AVR, which is faster than the 8-bit z80.

Reply to
linnix

Interesting. I'm in the middle of one like that, except for the monumental difference that the embedded hardware can run orthodox Linux, so we get the advantage of all the standard tools -- ssh, openvpn, etc. The downside is that I.T. tries to drag it away into Windows7/IIS, and it would be physically possible for them to do that.

Good Hunting, Mel.

Reply to
Mel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.