Microcontroller with authenticatino abilities

Hi,
what are the options to implement simple as possible MCU
with:
- around 2-4 I/O's
- 3mm by 3mm form factor 1mm thickness
- I2C conectivity additional to the I/O's from above
- Authentication abilities built in

for now i found some over kill:
http://www.atmel.com/Images/doc8024.pdf

how much complicated to implement authentication abilities on MCu which not have the auth. ability built in?

maybe it will be easier to implement Authentication SW on some simple cheap small MC instead of looking for a built in one. in such case can someone recommand for such simple MCu that i would be able to implement Auth. function on it?

can you just post the troubled area rather than an entire manual

I would like to have simple as possible MCu with Auth. functionality and i can't find such

then it is okay but posting an entire pdf was unwieldy

sorry but you didn't get me the PDF was example of something that i not looking for
i'm looking for something much simpler smaller

It depends on what kind of authentication you need. If you can implement it in software and can bit-bang 12C you can do it easily in a small SMD PIC10xxx series or 12Fxxxx series micro.

Brian.

Thanks this is the kind of answered i looked for

For me it is ok if possible to bit bang I2C (is it simple only by SW?)
&
i guess i would like to implement some standart auth. i.e. SHA 256 protocol
this will be the main function of my MCu. And in addition i would like to use few I/Os

But from where to start chosing the MCu?
How will i know that the PIC i choose will allow me to implement the bit bang of I2C and SHA 256?
How much: Memory, 4, 8, 16 bits? , OTP/EEPROM/SRAM/Flash
what i must have and what i can dismiss?

Thanks

bit bang of I2C i could found on the web.
regarding authentication SW implemetation- can someone lead me to any references of such SW implemetation on MCus?

SHA256 is fairly software intensive so you will need a reasonable amount of program storage and enough RAM to build the hash value. The byte size is almost irrelevant, you could use any size but 8-bit is probably easiest to code.

Whether it is OTP or not is entirely up to you and to some degree depends on how secure your code has to be. Functionally, OTP is exactly the same as non-OTP, only the ability to erase and re-use the IC is different. OTP (one time programmable) IC's are the same as their non-OTP parts but have the ability to wipe their contents disabled.

Again, you can use various types of memory but I would suggest Flash is the universal type to go for because it allows you to repeatedly erase and reprogram the IC during the debugging process and this is very useful, believe me, I've been doing it for years!

I've never coded a SHA256 algorithn but it I'm guessing it should be fairly easy to fit it inside one or two Kbytes of program.

I'm going to suggest you look at using the PIC12F1822 (8 pin) or PIC 12F1823 (14 pin), they are essentially the same apart from the number of IO pins. Both have built in I2C as well as loads of other peripherals. The assembler and simulator for them is free from the manufacturer and they can be programmed in high level languages using free or crippled compilers. For minimum cost and complexity, they both have built in clock oscillators although you can still use external clocks if you want to. Costs are very low, around $1 US in one-off quantities.

Brian.

Thank you for your kind answers it gives me some good leads,
i'll probobly have more questions soon after i'll go deaper with the implementation.

Many thanks

Hi Betwixt,

i found some info regarding the memory requirements for implementing the SHA-256 algoritem.

- Do you think PIC12F1822 or PIC 12F1823 can fit for this implementation?
- will this program be safe or someone might steal it?

Thanks

Do you think PIC12F1822 or PIC 12F1823 can fit for this implementation

Click to expand...

The numbers in your table clarify it can't.

It's never going to be 100% guaranteed secure, but it depends on if you're trying to stop 99.99% of users or 99.9999999% I suppose : )
I guess you're planning to pass some random values and expect the other side to hash it with some other content, send it back, and then compare the result with your own local hash? It means you need to have a very good random number scheme, so you need to consider that too, not just SHA-256. The procedure is essentially 'HTTP Digest' equivalent if you want to do some research on it. It's not perfect but secure enough unless you're apple (their annoying chips in their iPod video cables uses full-blown certificate based authentication as far as I can figure out, before I ditched apple products).

I don't know about SHA-256, but definitely for a fewer-bit version (SHA-1) you can find example C source code in an RFC doc if you google it. The C code may not be ideal for a microcontroller (I've not checked) but it's a good start, to be able to adapt it.

Since it's never going to be 100% secure, I'd suggest maybe a far simpler scheme is sufficient, to lock out 99.9% of users, e.g. just some stream of bytes, maybe a simple rolling code if you really want. Needs hardly any memory.
(Bear in mind people have cracked DVD, blu-ray etc, not that I know how..).

Those numbers are probably specific to one device, your requirement will depend on the code you write. Note that the figures are in bits, not bytes so they aren't as bad as first appears.

I'm not going to attempt to write code for you but my best guess is you could use one of those processors to do it. There are several implementations of SHA256 in Java on the internet. Obviously you can't directly run java in a small PIC but the method in the code should be adaptable.


Brian.

Many thanks

- - - Updated - - -

FvM - why you say it can't ? i cannot understand...

i cannot understand...

Click to expand...

Check the 12F1282x datasheets for available RAM.

FvM is right, I'm wrong - sorry.

You do need more RAM than the 12F182x devices so you would have to move to a 'bigger' PIC, possibly one of the PIC18 series would be more appropriate. The same software tools can be used to program them and they are still relatively inexpensive. If you go to www.microchip.com and click on the parametic selector it will let you choose which PIC is best suited to your application.

Brian.

Hey thanks,
the RAM size of 12F182x is 128x8,
How do you see/calculate its is not enough? sorry for ignorance. 2048/8= 256 ?
How much RAM will be enough for the SHA-256 ? 256 x 8 RAM?
Can it realy be safe by SW implementation ?
or anybody would be able to read the secret keys from the Flash memory? without problem.?
Thanks

- - - Updated - - -

Updated memory requirements for SHA-256 from Wikipedia.

Short answer:
Using SHA-256 will not be "really safe" in software, much more than SHA-1. Plus, you seem to be fixated on the hash method, but highly important is how you're going to generate your random numbers.
Regardless of your approach, I think you may need to study the algorithm in detail and make your own decision on how much resources it will need - some coders may need more resources, depending on how they code it up.
I've never needed to code or study the hash algorithms in detail, so I couldn't tell you if the wikipedia figures are correct. Maybe they are.
If you require (say) 256 bytes of a type of memory for an algorithm, then clearly you need more than 256 bytes to implement it and to run the rest of your software.
You could code it up, see how much memory it takes, and select the appropriate uC. As mentioned, SHA-1 code already exists in C so half your work is done.

Hey Sky, i'm not fixed on the hash method, i just want to unite auth.ic with Mcu
and that it be cheapst safest smallest etc.
for now all the auth.ics i searched were using the SHA-256, thats why i'm asking about this method.
if i had the knowlage of other safer SW auth. algo that can be easily implemented on cheap small minimal MCu i would be glad,
yet i'm missing of knowlage, i even don't yet understand how i can evaluate the memory requirements and specific Mc compliance w/ these requirements.
i also try to chose the right MCu before implementation but to have the garentiy that i'll be able to implement on the chosen in close future.