[Alg/Security]Secure communicatie tussen embedded devices

[farlane]

Voor een project ben ik belast met het ontwerpen van een methode om remote (embedded) devices op een veilige manier draadloos ( BTLE) met elkaar te kunnen laten communiceren. De devices hebben een hardwarematige AES engine aan boord, dus daar wil ik graag gebruik van maken voor de symmetrische encryptie die nodig is om de veilige verbinding op te zetten tussen de devices.
Voor het verkrijgen van sleutels voor dit verkeer ben ik uitgekomen op het (modified) Needham-Schroeder protocol. Er is dus een server S die bepaalt of een sleutel K_AB wordt uitgereikt aan B(en ook A) gebaseerd op het feit of de eigenaar van device B betaald heeft voor de services van device A.

De constructie waar ik op uitkom gaat er uiteindelijk van uit dat als device B een bericht van A ("challenge") kan decrypten en het goede antwoord kan terugsturen naar device A, dit voor device A een teken is dat device B inderdaad daartoe gemachtigd is door de server die de sleutel K_AB heeft uitgedeelt.

Nou ben ik nogal een nitwit op het gebied van security/encryptie, maar wat me wel duidelijk is geworden is dat als je ondanks de keuze voor bewezen technieken (AES,N-S protocol,...) je ergens een (denk)fout maakt je uiteindelijk het systeem behoorlijk lek kunt maken. Ik heb daarom de volgende vragen:

- Als je AES gaat gebruiken, welke mode of operation zou je in deze use-case dan moeten nemen? Moet het een authenticated mode zijn?
- Hoe belangrijk is het om de IV aan beide kanten random en hetzelfde te laten zijn? is dit ook belangrijk als het aantal brichten laag is?
- Is de aanname die ik schets dat het correct kunnen decrypten en beantwoorden van een challenge van A door B (in feite een identity check?) een correcte? (Misschien wel dezelfde vraag als de eerste)
- Hoe lang zou de verkregen key (eigenlijk een session key) geldig moeten zijn? Zijn dat uren? Dagen?

Mijn excuses voor de wat abstracte formulering, maar NDA en zo ....

[edit]
Inderdaad IV, thx

[RobIII]

farlane schreef op donderdag 20 november 2014 @ 12:22:
- Hoe belangrijk is het om de VI aan beide kanten random en hetzelfde te laten zijn? is dit ook belangrijk als het aantal brichten laag is?

Bedoel je hier niet IV? Die is vaak zelfs gewoon publiek en meestal (AFAIK) per bericht (of sessie) anders/nieuw.

[ Voor 13% gewijzigd door RobIII op 20-11-2014 12:28 ]

[farlane]

RobIII schreef op donderdag 20 november 2014 @ 12:26:
[...]

Bedoel je hier niet IV? Die is vaak zelfs gewoon publiek en meestal (AFAIK) per bericht (of sessie) anders/nieuw.

Klopt, er wordt gezegd dat het hergebuiken van de IV eigenlijk slecht is, maar om de decryptie goed te laten verlopen moet je deze (plain text) meesturen naar de decrypter. Op zich geen probleem, maar ivm met o.a. energieverbruik van de devices stuur ik liever kortere berichten dan langere. Ook het genereren van een goede IV kost energie.

[RobIII]

farlane schreef op donderdag 20 november 2014 @ 12:32:
stuur ik liever kortere berichten dan langere.
het genereren van een goede IV kost energie.

Dan zul je een trade-off moeten maken tussen goede/betere/sterkere encryptie en energie/netwerkbelasting etc.

[farlane]

RobIII schreef op donderdag 20 november 2014 @ 12:38:
Dan zul je een trade-off moeten maken tussen goede/betere/sterkere encryptie en energie/netwerkbelasting etc.

Inderdaad, maar om die afweging te maken zou ik willen weten hoeveel "slechter" de beveiliging wordt als je een constante IV neemt aan beide kanten bijvoorbeeld. Als ik het goed begrijp n.l. is het afhankelijk van de data of dit een probleem is: Als je data nooit ( of bijna nooit? ) hetzelfde is is het dan nog steeds zo belangrijk?

Overigens begin ik te twijfelen of dit wel het goede forum is; misschien hoort het wel bij Netwerken?

[Soultaker]

farlane schreef op donderdag 20 november 2014 @ 12:22:
- Als je AES gaat gebruiken, welke mode of operation zou je in deze use-case dan moeten nemen? Moet het een authenticated mode zijn?

Ja, encryptie zonder authenticatie heeft allerlei problemen.

- Hoe belangrijk is het om de IV aan beide kanten random en hetzelfde te laten zijn? is dit ook belangrijk als het aantal brichten laag is?

Hoe moeilijk is het om steeds een andere IV te genereren? De IV hoeft niet van hoge kwaliteit te zijn; mag zelfs oplopend zijn. Het gaat er vooral om dat 'ie uniek is (het is een zogenaamde nonce: number used once).

Bedenk trouwens dat als je individuele berichten versleutelt, je nog steeds kwetsbaar bent voor replay attacks. Dat kun je dan weer verhelpen door elk bericht van een timestamp te voorzien en alleen strict oplopende timestamps te accepteren.

[farlane]

Soultaker schreef op vrijdag 21 november 2014 @ 10:46:
[...]

Ja, encryptie zonder authenticatie heeft allerlei problemen.

Ok da's duidelijk.

Hoe moeilijk is het om steeds een andere IV te genereren? De IV hoeft niet van hoge kwaliteit te zijn; mag zelfs oplopend zijn. Het gaat er vooral om dat 'ie uniek is (het is een zogenaamde nonce: number used once).

Niet zozeer moeilijk, maar het is een extra overhead in o.a. het bericht, en dat heeft (een nog onbekende) invloed op het energieverbruik van de devices, vandaar de overweging.
Op dit moment ga ik er van uit dat de IV per sessie gegenereerd gaat worden en met de start van de sessie meegestuurd.

Bedenk trouwens dat als je individuele berichten versleutelt, je nog steeds kwetsbaar bent voor replay attacks. Dat kun je dan weer verhelpen door elk bericht van een timestamp te voorzien en alleen strict oplopende timestamps te accepteren.

Het N-S protocol voorziet hierin, maar het "challenge" gedeelte heb ik in feite zelf toegevoegd en ik ben erg benieuwd of de aannames die ik daar doe correct zijn. Misschien dat je je licht daar op zou willen laten schijnen?

Het gaat ongeveer zo:

code:

B -> A : Request service
A -> B : { Nonce } Kab
B -> A : { Nonce - 1 } Kab
A : Activeer service

Maw, het feit dat B de nonce kan decoderen en een correct antwoord kan geven op de challenge is voor A een teken dat de service gactiveerd mag worden.

[Ghehe]

Het lijkt dat je vulnerable bent voor een MITM aangezien je geen authenticatie gebruikt voor A. (B weet dus niet zeker dat het met A praat)

code:

B -> C : Request service

C -> A : Request service
A -> C : Nonce

C -> B : Nonce
B -> C : Nonce - 1

C -> A : Nonce - 1
A -> C : Activeer service

[farlane]

Ghehe schreef op vrijdag 21 november 2014 @ 13:29:
Het lijkt dat je vulnerable bent voor een MITM aangezien je geen authenticatie gebruikt voor A. (B weet dus niet zeker dat het met A praat)

code:

B -> C : Request service

C -> A : Request service
A -> C : Nonce

C -> B : Nonce
B -> C : Nonce - 1

C -> A : Nonce - 1
A -> C : Activeer service

Je hebt gelijk, dank u voor de slap in the face Dat bedoel ik dus met hoe makkelijk het is om een fuckup te maken bij dit soort dingen..
Is er een manier om de identity van A (en B? ) te verifieren zonder dat er een 3e partij aan te pas komt tijdens dit proces?

[Rukapul]

Ik zou adviseren om Cryptography Engineering van Ferguson et.al. eens erbij te pakken. Dat zal heel verduidelijkend zijn m.b.t. block cipher modes, de combinatie van authentication en encryptie, het belang van IVs, etc.

Tevens is het kansloos om bij voorbaat een paar bytes voor een IV af te schrijven. Dat is nou een klassiek geval van premature optimization waar al veel onveilige systemen uit voort zijn gekomen.

Voor welke actor is het energieverbruik bijvoorbeeld van belang? A, B, beide, Server? Het aantal berichten in het totaal protocol (N-S key estalishment + authorisatie protocol) voor een bepaalde partij is bijvoorbeeld meer van belang dan een enkele byte ergens.

Sowieso is het waarschijnlijk qua energie een non-probleem aangezien zo'n setup naar ik mag aannemen slechts eenmaal tussen een paar devices wordt uitgevoerd. Ik neem tenminste aan dat het resultaat van de key agreement als input gaat gelden voor reguliere BTLE encryptie?

Vragen, vragen

[farlane]

Rukapul schreef op vrijdag 21 november 2014 @ 15:39:
Ik zou adviseren om Cryptography Engineering van Ferguson et.al. eens erbij te pakken. Dat zal heel verduidelijkend zijn m.b.t. block cipher modes, de combinatie van authentication en encryptie, het belang van IVs, etc.

Dank.

Tevens is het kansloos om bij voorbaat een paar bytes voor een IV af te schrijven. Dat is nou een klassiek geval van premature optimization waar al veel onveilige systemen uit voort zijn gekomen.

Zoals aangegeven schrijf ik het niet bij voorbaat af, ik ga er van uit dat ik een IV moet meesturen. De reden dat ik de vraag stel is omdat ik me afvraag *of* ik het ueberhaubt kan afschrijven. Als het kan, dan doe ik het.

Voor welke actor is het energieverbruik bijvoorbeeld van belang? A, B, beide, Server?

A en in mindere mate B, server niet.

Het aantal berichten in het totaal protocol (N-S key estalishment + authorisatie protocol) voor een bepaalde partij is bijvoorbeeld meer van belang dan een enkele byte ergens.

N-S zal minder vaak worden uitgevoerd, het activeren van de service potentieel veel vaker dus als je daar een IV moet meesturen kan dat invloed hebben op het verbruik.

Sowieso is het waarschijnlijk qua energie een non-probleem aangezien zo'n setup naar ik mag aannemen slechts eenmaal tussen een paar devices wordt uitgevoerd.

Niet eenmalig, aangezien B kan wisselen.

Ik neem tenminste aan dat het resultaat van de key agreement als input gaat gelden voor reguliere BTLE encryptie?

Was ik eigenlijk niet van plan aangezien ik dit tegenkwam : Bluetooth: With Low Energy comes Low Security

[Rukapul]

De BTLE weakness zit in de null en PIN authentication, niet in de full provisioned key variant. Die laatste wordt echter niet altijd ondersteund en je zou dan dus moeten beginnen met BTLE zonder authentication en na je protocol opnieuw moeten pairen met de full key. Uitzoekklus.

BTLE neemt verder wel je authenticated encryption uit handen.

[Rukapul]

farlane schreef op vrijdag 21 november 2014 @ 16:50:
A en in mindere mate B, server niet.

Als A het meest critisch is dan is het wellicht niet ideaal om 5 N-S protocol interacties met A uit te voeren en 3 voor de authorisatie...

N-S zal minder vaak worden uitgevoerd, het activeren van de service potentieel veel vaker

Op basis van wat je hierboven schrijf heb je een fout in je security design. Immers Kab is het geheim wat uit N-S voortkomt en gebruikt wordt bij de service authorisatie check. Die twee zijn dus een-op-een met elkaar verbonden.

Ghehe schreef op vrijdag 21 november 2014 @ 13:29:
Het lijkt dat je vulnerable bent voor een MITM aangezien je geen authenticatie gebruikt voor A. (B weet dus niet zeker dat het met A praat)

Natuurlijk niet. Het doel is slechts dat A kan bepalen of B het gedeelde geheim kent als bewijs van het geautoriseerd zijn. B hoeft niet te weten dat hij met A praat (die requirement is niet gesteld).

Al met al moeten de objectives en requirements duidelijker verwoord worden. Daarna is een (efficientere) oplossing mogelijk.

Er is dus een server S die bepaalt of een sleutel KAB wordt uitgereikt aan B(en ook A) gebaseerd op het feit of de eigenaar van device B betaald heeft voor de services van device A.

Als dit exact zo is dan is de extra authorisatie validatie in het geheel niet nodig. Het niet beschikbaar maken van Kab aan A en B (via A) door S is dan al voldoende. Een status code ter signalering is hiervoor geschikt.

[ Voor 14% gewijzigd door Rukapul op 22-11-2014 10:27 ]

[farlane]

Rukapul schreef op zaterdag 22 november 2014 @ 09:53:
Als A het meest critisch is dan is het wellicht niet ideaal om 5 N-S protocol interacties met A uit te voeren en 3 voor de authorisatie...
[...]
Op basis van wat je hierboven schrijf heb je een fout in je security design. Immers Kab is het geheim wat uit N-S voortkomt en gebruikt wordt bij de service authorisatie check. Die twee zijn dus een-op-een met elkaar verbonden.

Misschien ben ik niet duidelijk geweest, maar de sleutel Kab wil ik gebruiken als "sessiesleutel", dwz voor elke run van het N-S protocol is de sleutel Kab een langere tijd geldig om de service op A meerdere te activeren, de gelidgheidsduur wordt bepaald op server S.

Natuurlijk niet. Het doel is slechts dat A kan bepalen of B het gedeelde geheim kent als bewijs van het geautoriseerd zijn. B hoeft niet te weten dat hij met A praat (die requirement is niet gesteld).

Nou, er zit volgens mij wel een mogelijk gat : als C de challenge van A kan later beantwoorden door B ( die Kab heeft ) kan C ook de service op A activeren. Classificeert misschien niet als MITM maar toch ... ik moet nog verder denken of het in mijn geval echt een probleem is : het is nl niet zo dat C zonder B de service kan activeren.

Al met al moeten de objectives en requirements duidelijker verwoord worden. Daarna is een (efficientere) oplossing mogelijk.

Ik weet niet goed hoe ik mijn use case duidelijker moet maken zonder in de knoei te komen met de NDA

Als dit exact zo is dan is de extra authorisatie validatie in het geheel niet nodig. Het niet beschikbaar maken van Kab aan A en B (via A) door S is dan al voldoende. Een status code ter signalering is hiervoor geschikt.

Ik denk dat dit voorkomt uit het misverstand wat ik noemde? Het is dus de bedoeling dat B de service op A kan activeren zonder verdere tussenkomst van S : Deze doet alleen mee tijdens de initiele activatie/het uitdelen van de "sessiesleutel" Kab. Deze sleutel heeft wel dus een geldheidsduur, op een gegeven moment zal A de sleutel verwijderen en zal de sleutel ververst moeten worden m.b.v. S.