X.509 certificates on small micros?

We already individually program many of these devices with MACs and other u= nit-specific data (how do you think it gets a UUID in the first place? :). = Adding crypto information is not anything complicated, we already have auto= mated systems for that. An external program generates the binary blob of co= nfiguration data and passes it to in-circuit programming.

Non-unique UUIDs (e.g. from someone at the factory copying the data stream)= would be immediately detected over the Internet once the device comes into= use. The only thing we could not easily stop is the factory making extras = and selling them out the back door - as long as the UUID is in our database= , and the location of checkin is unique, we would consider it a valid devic= e.

I should point out btw that none of the devices in this system are a PC.

So is it MIPS or MHz? I do not think it is the same thing for an 8-bit AVR..

BTW, my z80 ran at 15MHz, but no MULs - huge disadvantage when it comes to RSA :(

AVR instructions are single cycle.

Xmega runs at 32MHz, but no USB version, unfortunately.

Most instructions on the 8-bit AVR require only one cycle. So on the

8-bit AVR 1 MHz roughly equals 1 MIPS.

An 8-bit AVR is much faster than a Z80 at the same clock frequency, even without a multiply instruction.

I mean that right now both systems are 8 bits, usually (a few specific devi= ces are 16 or 32 bits). This is actually an ecosystem of devices, and we wa= nt to make sure that new devices putting content into the ecosystem are pro= perly licensed to do so. I will split up the workload in such a way as to e= nsure the minimum number of devices have to be upgraded. Maybe we will make= a hub device that does all the authentication and nothing else.

OK, good info.

1Kbit minimum, 2Kbit would be better.

Correct.

It doesn't have to happen often, and could be done as a background task. 30= seconds would be livable.

Yes but it was just an example. Some of the 8-bit micros we use do not have= HW MUL.

That is a very good piece of info. What was the flash and RAM footprint of = this code?

Thanks.

vices are 16 or 32 bits). This is actually an ecosystem of devices, and we = want to make sure that new devices putting content into the ecosystem are p= roperly licensed to do so. I will split up the workload in such a way as to= ensure the minimum number of devices have to be upgraded. Maybe we will ma= ke a hub device that does all the authentication and nothing else.

30 seconds would be livable.

ve HW MUL.

f this code?

Apparently, we live in different time zones. I've had my glass of wine already (thanks God it's Friday), so I won't answer to avoid saying something utterly stupid :) The topic is very interesting, though, so let's hope it'll survive for a while.

MUL.

That's going to seriously restrict the kind of crypto you can afford. Private-key ciphers like AES can sometimes make do without MUL. But authenticators like RSA usually can't.

Be sure you have a back-up plan in place for when this turns out to be a complete show-stopper.

Forking forkety fork. Google Groups "new" interface is even worse than the = old one and is functionally broken to boot! It does however show this entir= e thread as a single thread (though really hard to read because of the scre= wed-up hemi-demi-semi-tree format).

See above... it was idiot proof, then they invented a better idiot.

=20

It is within my power to dictate that those platforms which can't support t= he requirement shall be upgraded or discontinued. The reason I am gathering= this background info is that I want a good quantitative rebuttal when some= one reads my spec - or glances through it - and says in kneejerk fashion "i= t's too expensive". Such someones have in the past said, for example, "AES = is too expensive to do - we'd need to upgrade from AVR to ARM" - while in f= act we ALREADY implement AES in the AVR-based products in question :)

Heh. Well, you make a very good point - I just got home from a very hard we= ek, I should unstrap the Blackberry from my waist and go to the local Greek= restaurant for some red wine, tzatziki and a good salad with plenty of fet= a and olives. Mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.

Of course the title is ambiguous, because "small micro" is an undefined ter= m. Used to mean an 8051 with 128 bytes of RAM, now could mean 128KF/32KR an= d a 75MHz+ ARM core :)

certificate on a device before I allow it to interact

Are you sure you need to use assymetric cryptography? That is, why can't you just use a simple challenge-response system based on a shared secret?

If you can protect the ROM from unauthorized access (i.e. protect the shared secret, CHAP is pretty simple:

0) Client and server have a copy of a shared secret 1) Send a challenge nonce (random number) to the client 2) Client creates salt (a small random number against replay attacks) 3) Client makes a SHA-1 or MD5 digest of the secret, the salt and the challenge 4) Client sends the salt and the digest back to the server 5) Server repeats #3 and verifies the correct result.

Much simpler way to do things. Assymetric cryptography is way over-rated, being useful where the respondents have no mutual trust nor shared secrets, but both trust some third party.

Clifford Heath.

week, I should unstrap the Blackberry from my waist and go to the local Gre= ek restaurant for some red wine, tzatziki and a good salad with plenty of f= eta and olives. Mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.

Good morning (my morning) (and thanks God it's Saturday) :)

erm. Used to mean an 8051 with 128 bytes of RAM, now could mean 128KF/32KR = and a 75MHz+ ARM core :)

Still have little time, so a couple of quick questions more:

1) Is the MUL instruction executed in a single cycle too? (On that 8- bit AVR) 2) (slightly on a different topic) Can it shift a register by multiple bits in a single cycle? (thinking of SHA now).

I'll come back here a bit later.

larwe schrieb:

[...]

It would really be nice if you wouldn't start a new thread for every reply you send.

Seems to be a setting of your google groups account, or wrong handling of it, or one more malfunction of terrible google groups - but please correct that (other google groups posters also provide correct references).

Thanks, Tilmann

The MUL instruction takes 2 cycles, and shifts are single bit only. There is a however a SWAP instruction that swaps the 2 nibbles in a byte.

Yes. Some of the systems are developed by third parties. We need to be able to revoke certification for systems if partnerships go sour.

).

I'm not seeing anything like this (or is this already corrected?) I use Google Groups via Internet Explorer at the moment, this link:

Google Groups works fine with Google Groups postings. Unfortunately the "New" Google Groups (click the link on the right-hand side of that page you're on) has this known issue, which already has a few dozen complaints in the feedback forum.

Now I'm switched over I don't know how to get back :/

2 cycles for 8 x 8 -> 16, what a luxury! :) Ok, more rough, ballpark figures: if 16Mhz AVR can do the public key RSA for 1024 bit key in 1 second (as someone said, I have no ways to verify this), and I assume the exponent =3D 2^16 + 1 was meant(?) Then we're talking about 6-8 seconds for the same operation on 2048 bit key. To get the idea about a private key operation, you should multiply the above figures by, say, 100 - 120 (depends on many things). [Now, an angry bunch of professionals are going to come and start corecting my figures - welcome :)]

In principle I agree, though since next week is finals for me I'm not so thrilled to be in the weekend mode.

Two cycles.

No; LSL, LSR, ROL, ROR are one bit at a time.

New" Google Groups (click the link on the right-hand side of that page you'= re on) has this known issue, which already has a few dozen complaints in th= e feedback forum.

Aha, I see what you mean now - just don't use that New Google Groups then...