iemand ervaring met hardware crypto ic's

Ik zou het "device" upgraden naar een ESP32, kost niet of nauwelijks meer dan de AVR, De ESP32 heeft een Cryptographic HW accelerator intern voor SHA, AES, RSA (bignum) en RNG.

Een losse crypto chip heeft tevens het nadeel dat de communicatie tussen de AVR en de crypto chip af te vangen is.

de esp heeft veel te weinig io/ peripherals die mijn applicatie nodig heeft. Daarnaast gaat het hier om een bedrade ethernet applicatie.

Volgens mij is het idee dat de communicatie af te vangen is juist geen probleem.
Anders zouden die crypto chips geen bestaansrecht hebben.
Het diee is dat daar af fabriek of in productie keys worden in geprogrammeerd die er vervolgens niet meer uit te lezen zijn.

Je stuurt er een challenge naar toe (die is niet geheim) en het crypto IC geeft daar een antwoord op, dat alleen gegeven kan worden als je de correcte key hebt (die heb je er tijdens productie immers ingezet).
Wat de relatie tussen challenge en antwoord is blijft dus geheim.

Als de challenges random zijn en de webserver bijhoud welke al eens zijn uitgegeven voorkom je een replay attack volgens mij.

Echt volledig SSL of beter genoemd TLS kan denk ik het beste vanuit de software. Ik zie even niet in hoe een apart crypto IC hier handiger gaat worden dan de controller zelf upgraden. Tenzij je vast zit aan speciale software en IO eisen en daardoor de communicatie bijvoorbeeld door een ESP8266 doet.

Je kan zelf natuurlijk ook veel doen in software:

Een sleutel in het URL zodat je de webserver al veel kan afvangen:

http://myserver.com/Ftt6KLlo976DLBEU3/api/call?value=123

Zo kan de webserver of applicatie ook al heel vroeg afvangen:
http://myserver.com/api/call?value=123&key=Ftt6KLlo976DLBEU3

Dan kan je die sleutel nog 'seeden' bijvoorbeeld met de datum..
Op de server moet je dan wel zo ruimhartig zijn om een dag eerder of later ook te accepteren.
En dat kan je met de waardes ook doen.

Microcontroller met crypto engine (bijv. de PIC24FJ256GA410) is veiliger als losse chips...
Of kleiner: de PIC24FJ128GA202

[Bericht gewijzigd door Arco op woensdag 6 november 2019 10:28:55 (24%)

I know I know, voor een redesign van het systeem ga ik zeker kijken naar een arm die wel TLS kan doen, maar nu is dat even geen optie. Die slutel in Url kan inderdaad ook, maar daarmee heb ik geen garantie dat mijn node is wie ik verwacht.
Ik heb nu alleen geen tijd / zin / budget om mijn software te porten naar een andere processor en mijn hardware design op de schop te gooien.

Wat is het bestaansrecht van deze losse crypto ic's dan?
Ze hebben toch degelijk een functie lijkt me.
Heeft niemand ze ooit toegepast?

[Bericht gewijzigd door Stijnos op woensdag 6 november 2019 10:37:36 (16%)

Is er voor die processor die je gebruikt dan geen crypto software beschikbaar?
(Zelfs voor kleine 16F PIC's is die er. Nadeel: is wel erg traag uiteraard (100+mS decrypt)

Volgens mij kan je al heel redelijke security krijgen (binnen de scope die je hebt gegeven) door een challenge achter de "secret key" te zetten en daar de SHA van uit te rekenen. Dat is dan je "auth token". Een AVR zou een SHA256 gewoon moeten kunnen uitrekenen. Zoveel kost dat niet. Ik zie dat er een avr-crypto library is.

Die secret key moet je dan in je device programmeren en readout protectie moet je aanzetten.

Die readout protectie is kennelijk te kraken, maar het is moeilijker dan gewoon het device in een programmer....

Edit: Als je de "heen-en-weer" voor de challenge wil voorkomen, dan doe je iets als

key = hash (secret + serialnr);

en dan stuur je in je webrequest het serialnr mee. Hergebruik van serialnummers strikt verboden, en de webserver moet accepteren dat je er een zwik overslaat (dan was ie kennelijk niet bereikbaar vanuit je device).

[Bericht gewijzigd door rew op woensdag 6 november 2019 11:07:58 (24%)

ik gebruik een atmega2560 icm een W5500 ethernet driver, maar wat moet ik dan met crypto software?
TLS ga ik nooit voor elkaar krijgen.

Ik dacht dus de webserver stuurt een challenge. Laten we even zeggen dat dit de huidige datum + tijd is (totaal niet random, maar even voor het voorbeeld hier) Deze challenge wordt naar een crypto ic gestuurt die op basis van een intern opgeslagen key (die enkel mij bekend is) daarop een response genereerd.
Deze response wordt terug gestuurd naar de webserver.

De webserver berekend van de verstuurde challenge met dezelfde key ook de response en kijkt of beide matchen. Zoiets vraagt van mijn AVR niet meer dan wat i2c communicatie met het crypto ic en deze communicatie is niks geheims aan.
Als ik deze reponse dan als soort van session key gebruik op mijn api die maar x tijd geldig is zou dat toch een oplossing kunnen zijn?

Op 6 november 2019 11:04:26 schreef rew:
Volgens mij kan je al heel redelijke security krijgen (binnen de scope die je hebt gegeven) door een challenge achter de "secret key" te zetten en daar de SHA van uit te rekenen. Dat is dan je "auth token". Een AVR zou een SHA256 gewoon moeten kunnen uitrekenen. Zoveel kost dat niet. Ik zie dat er een avr-crypto library is.

Die secret key moet je dan in je device programmeren en readout protectie moet je aanzetten.

Die readout protectie is kennelijk te kraken, maar het is moeilijker dan gewoon het device in een programmer....

Edit: Als je de "heen-en-weer" voor de challenge wil voorkomen, dan doe je iets als

key = hash (secret + serialnr);

en dan stuur je in je webrequest het serialnr mee. Hergebruik van serialnummers strikt verboden, en de webserver moet accepteren dat je er een zwik overslaat (dan was ie kennelijk niet bereikbaar vanuit je device).

@rew, jou oplossing ga ik even laten bezinken. Dat komt inderdaad in de buurt van mijn idee volgens mij

[edit]sorry voor de dubbel post, had op het verkeerde knopje gedrukt [/edit]

[Bericht gewijzigd door Stijnos op woensdag 6 november 2019 11:16:49 (67%)

Misschien is een SECURITY SHIELD (W5500 Ethernet Shield S) iets voor jouw ?

https://wizwiki.net/wiki/doku.php/products:securityshield:start

Op 6 november 2019 10:36:29 schreef Stijnos:...

Wat is het bestaansrecht van deze losse crypto ic's dan?
Ze hebben toch degelijk een functie lijkt me.
Heeft niemand ze ooit toegepast?

Geen idee, komen die uit een tijd dat 1MHz nog veel was of bijvoorbeeld satellietdecoder behoorlijk veel data moest decoderen met zo'n smartcard?

Op 6 november 2019 11:18:41 schreef K7Jz:
[...]

Geen idee, komen die uit een tijd dat 1MHz nog veel was of bijvoorbeeld satellietdecoder behoorlijk veel data moest decoderen met zo'n smartcard?

nee dat geloof ik niet.
Volgens mij is de kracht vooral dat ze het mogelijk maken om secure keys op te slaan. Opslaan in je firmware of micro flash is eigenlijk uit den boze.
Ook al wordt dat veel gedaan. Maar dat is dan als het belang groot genoeg is gewoon uit te lezen. Die crypto IC's hebben vaak een beschermde die tegen decappen van IC's om zo toch firmware uit te lezen of whatever.

Voor veel toepassingen paranoia, maar met alles geld als het belang maar interessant genoeg is wordt het gedaan en als jouw bedrijf toen dacht dat gebeurt niet of daar gaan we niet een paar cent extra aan uitgeven en heel je infrastructuur wordt gehackt of openbaar gemaakt dan kun je je product / bedrijf wel opdoeken.

Tegenwoordig heb je wel steeds vaker secure storage in micro processoren, alleen zijn die nog best schaars.

Als het alleen om een soort grove beveiliging gaat kun je bijv. data en password laatste byte XOR'en en dan een rotate left tot data op is.
Ontvangende server doet 't zelfde bij ontvangst en heeft de data weer terug. Simpel maar voor niet kritische toepassingen vaak genoeg.

Beveiligingen schieten ook vaak door, Ik heb er complexe gezien waar zo vaak wat misging dat de klanten weg begonnen te lopen...

Op 6 november 2019 12:07:37 schreef Arco:
Als het alleen om een soort grove beveiliging gaat kun je bijv. data en password laatste byte XOR'en en dan een rotate left tot data op is.
Ontvangende server doet 't zelfde bij ontvangst en heeft de data weer terug. Simpel maar voor niet kritische toepassingen vaak genoeg.

[bijlage]
Beveiligingen schieten ook vaak door, Ik heb er complexe gezien waar zo vaak wat misging dat de klanten weg begonnen te lopen...

maar daarmee zorg ik toch alleen maar dat data en password niet meer leesbaar zijn.
Maar het resultaat daarvan kan door iedereen toch weer gebruikt worden op de api?

zelfde idee is dat ik niet mijn password als plain text wil sturen, maar de hash daarvan.

Als iemand anders diezelfde hash gebruikt dan is er toch nog niks verbeterd? of begrijp ik je verkeerd?

Stuur je een wijzigende sleutel mee vanaf de server encrypted met het 'vaste' password. Ben je daar vanaf...
Ikzelf ben niet zo'n voorstander van encryptie als 't niet echt nodig is uit veiligheidsoverwegingen.
Ik heb er genoeg gezien die meer problemen gaven als dat ze oplosten (FTDI is een goed voorbeeld)

Als je key op beide punten bekend is dan weet een aanvaller niet hoe hij aan een wisselend resultaat komt. Zelfs een eenvoudige teller of de tijd XOR'en met de key maakt het dan al lastig. Helemaal als je dit verzendt:

Base64_encode( waarde XOR key XOR datum XOR teller )

Verder natuurlijk: ga je hier de encryptie voor de ING of Nuon doen of is het gewoon mkb koelcelbewaking.

[Bericht gewijzigd door K7Jz op woensdag 6 november 2019 12:47:41 (31%)

Het is in de orde van het laatste. Geen ING of nuon nee
Maar als ik datum key en teller XOR dan moet server ook wel die teller in sync hebben toch of kan hij die eruit filteren en negeren of eventueel opslaan om rwplay te negeren?

Je kan de teller na 5 minuten geen verbinding resetten naar 0. Of je pakt de eerste 8 bytes van de vorige lading, mits X minuten geleden.

Je kan ook nog iets met het IP adres doen natuurlijk.