RSA encryption om herkomst van een bestand te checken

[NickThissen]

Ik heb een probleem bij het toepassen van asymmetrische encryptie (RSA) om de herkomst van een bestand te verifieren. Ik zal eerst kort uitleggen wat de context is en daarna wat ik probeer te doen.

Ik heb een Windows applicatie gemaakt welke door derden gebruikt wordt. Voor het gemak kunnen we het even voorstellen als bijvoorbeeld Powerpoint. Echter in mijn geval worden de "presentaties" enkel door mij gemaakt. Ik wil niet dat iemand anders zijn eigen presentaties kan maken (of in ieder geval mag hij ze niet kunnen openen in mijn applicatie). Simpel gezegd is de applicatie ("Powerpoint") gratis maar verkoop ik de "presentaties", ik wil dus niet dat mensen die kunnen aanpassen of op welke manier dan ook hun eigen presentaties kunnen maken.

De presentaties bestaan in principe simpelweg uit een zipfile met de benodigde bestanden, welke ik daarna ofwel encodeer of encrypt met simpele symmetrische encryptie (gewoon zodat ze niet met winzip etc gelezen kunnen worden). Het maken en daarna encrypten van de zipfile gebeurt in een aparte applicatie, en alleen ik heb deze applicatie, niemand anders heeft toegang tot de source code en zelfs niet de executable.

Om ervoor te zorgen dat mensen niet hun eigen presentaties kunnen maken of kunnen aanpassen had ik bedacht dat ik RSA encryptie kan gebruiken. Het concept had ik als volgt bedacht:

In mijn prive applicatie welke de presentaties maakt gebeuren deze stappen:

1. Maak een (MD5) hash van de zipfile
2. Gebruik mijn private key om deze hash te encrypten. Het resultaat noem ik de "symmetric key". De private key is alleen bekend in mijn prive applicatie.
3. Gebruik de symmetric key om de contents van de zipfile te encrypten.
4. Voeg de data in raw bytes samen als "symmetric key" + "encrypted zipfile".
5. Deze data is wat uiteindelijk verstuurd wordt als "de presentatie".

In mijn "Powerpoint" kan deze data dan als volgt geladen worden:

1. Lees apart de bytes van de symmetric key en de rest van de data (ga er even vanuit dat ik de lengte weet of ook meestuur).
2. Gebruik de symmetric key om de rest van de data te decrypten. Het resultaat is de relevante data (gezipt) die mijn Powerpoint kan lezen.
3. Gebruik de public key (in "Powerpoint" meegestuurd dus publiek bekend) om de symmetric key te decrypten. Het resultaat zou de hash moeten zijn van de decrypted zipfile.
4. Check of de hash inderdaad gelijk is aan de hash van de decrypted zipfile. Zo ja, dan is alles ok. Zo nee, dan is de zipfile aangepast en de verkeerde key meegestuurd --> fout.

In mijn gedachten klopt dit helemaal. Ik gebruik RSA om een key te maken die een grote file kan encrypten en weer decrypten. Ik hou mijn private key geheim en distribueer alleen de public key. Ik zie geen manier waarop iemand nu nog (zonder mijn private key) een eigen presentatie kan maken, aangezien de hash van zijn presentatie gelijk moet zijn aan de RSA(symmetric key), maar die kan hij niet maken want hij heeft de private key niet.


Nu komt het enige punt waar dit compleet mis loopt; iemand met ervaring heeft het vast al lang gezien. Ik kom er echter net achter dat de private key niet gebruikt kan worden voor encryption maar alleen voor decryption.

Het idee van RSA is blijkbaar dat je met de private key iets kan decrypten maar niet kan encrypten. Mijn hele concept werkt dus niet.

Ik kan ook niet "gewoon" de keys omdraaien (public key geheim houden en private key meesturen), want met de private key kan iedereen de public key gewoon berekenen, dus dan heeft het geen zin meer om die geheim te houden.

Ik maak waarschijnlijk een cruciale fout maar ik snap niet hoe ik dit kan implementeren. Moet ik iets radicaal anders verzinnen of kan ik dit op een iets andere manier toch werkend krijgen?

[Juup]

Je moet 2 dingen uit elkaar houden:
- Je wilt niet dat mensen (de inhoud van) je zip kunnen lezen
- Je wilt verifieren dat de zip gemaakt is door iemand die "het geheim" kent

Probleem #1 is fundamenteel onoplosbaar want de zip moet gelezen kunnen worden door je "powerpoint" en dus is het op de PC van de gebruiker decrypted beschikbaar (in geheugen of op disk)

Probleem #2 is prima oplosbaar met public/secret keys waarbij de public key door de "powerpoint" gebruikt kan worden om de signature te verifieren.
_{Behalve dat iemand met wat volharding zijn eigen public/secret keys kan maken en die public injecteren in jouw "powerpoint".}

[ Voor 10% gewijzigd door Juup op 04-02-2019 17:54 ]

[NickThissen]

Juup schreef op maandag 4 februari 2019 @ 17:43:
Je moet 2 dingen uit elkaar houden:
- Je wilt niet dat mensen (de inhoud van) je zip kunnen lezen
- Je wilt verifieren dat de zip gemaakt is door iemand die "het geheim" kent

Probleem #1 is fundamenteel onoplosbaar want de zip moet gelezen kunnen worden door je "powerpoint" en dus is het op de PC van de gebruiker decrypted beschikbaar (in geheugen of op disk)

Probleem #2 is prima oplosbaar met public/secret keys waarbij de public key door de "powerpoint" gebruikt kan worden om de signature te verifieren.
Behalve dat iemand met wat volharding zijn eigen public/secret keys kan maken en die public injecteren in jouw "powerpoint".

Probleem 1 is niet zo van belang inderdaad. Iemand mag best achterhalen dat de files gewoon zipfiles zijn en de inhoud unzippen. Zolang ze maar niet een verandering kunnen maken, opnieuw kunnen zippen en daarna kunnen gebruiken. Dit is probleem 2 dus.

Ik zie echter nog geen oplossing voor probleem 2. Voor zover ik kan zien moet ik de hash kunnen encrypten met m'n private key, maar dat kan dus blijkbaar niet.

Als ik Wikipedia lees dan staat het juist weer letterlijk dat het wel kan (punt 2):

Thus, the keys may be swapped without loss of generality, that is a private key of a key pair may be used either to:

1. Decrypt a message only intended for the recipient, which may be encrypted by anyone having the public key (asymmetric encrypted transport).
2. Encrypt a message which may be decrypted by anyone, but which can only be encrypted by one person (signature).

Dit is wat ik wil, maar de libraries die ik heb geprobeerd (bijv BouncyCastle) staan me niet toe om een encryptie te doen met de private key. Na wat Googlen kwam ik tot de conclusie dat encryptie alleen met de public key zou moeten.

Nu ik echter nog wat meer door zoek begrijp ik denk ik mijn fout: ik wil gebruik maken van signing en niet encryption. En signing kan wel met de private key. Enkel wat is het verschil in de praktijk?

[NickThissen]

Juup schreef op maandag 4 februari 2019 @ 17:43:

_{Behalve dat iemand met wat volharding zijn eigen public/secret keys kan maken en die public injecteren in jouw "powerpoint".}

Kun je dit uitleggen? Hiervoor moet iemand dus een soort kopie van mijn "Powerpoint" maken die een andere key gebruikt? In dat geval is het natuurlijk veel makkelijker om een kopie te maken waarin deze hele check gewoon niet gedaan wordt lijkt me. Daar ben ik niet zo bang voor, met wat simpele obfuscation is dat al meteen erg lastig en dat is voor mij goed genoeg momenteel.

[Juup]

Signen doe je om te bewijzen dat de inhoud niet gewijzigd is.
Encrypten doe je zodat de inhoud niet gelezen kan worden.

[DJMaze]

1. signeer de data
2. stop de signature + data in de zip
3. applicatie haalt data uit de zip
4. applicatie checkt de signature van de data

Je kan dan ook prima i.p.v. zip kiezen voor tar.gz, tar.bz, 7zip, etc. etc.

In alle gevallen kan iemand nog steeds zelf iets maken als ze jouw public key vervangen met die van hun.

[ Voor 38% gewijzigd door DJMaze op 11-02-2019 17:00 ]

[NickThissen]

Ik denk dat het gelukt is. Ik dacht inderdaad verkeerd over encryptie en signing. Wat ik wil is signing en dat kan prima met de private key (en daarna verification met public key).

Inmiddels heb ik het werkend, bedankt voor de tips

DJMaze schreef op dinsdag 5 februari 2019 @ 08:48:
In alle gevallen kan iemand nog steeds zelf iets maken als ze jouw public key vervangen met die van hun.

Dit snap ik nog niet. Bedoel je dat ze hun "presentatie" signeren met hun eigen nieuwe private key, en daarbij een bijbehorende nieuwe public key gebruiken om hem weer te verifieren? In dat geval moeten ze mijn "Powerpoint" applicatie dus op een of andere manier hacken om deze public key te laten gebruiken? Hoe zou dit in de praktijk werken, kan iemand met wat kennis de executable aanpassen en onze public key daarin opzoeken en veranderen?

Ik snap dat een dergelijk systeem nooit waterdicht zal zijn maar dat hoeft ook niet, het is vooral belangrijk dat mensen niet simpelweg mijn presentaties kunnen unzippen, kunnen veranderen en daarna weer kunnen zippen en direct gebruiken. Momenteel, in de oude versie, is het gewoon een zipfile die met een symmetrische encryptie "onleesbaar" gemaakt is, maar die encryptie is gemakkelijk ongedaan te maken door iemand die de executable decompiled. Met toevoeging van het signeren met een private key wordt het dus al een stuk lastiger omdat ze daadwerkelijk mijn executable moeten gaan aanpassen om het werkend te krijgen. Begrijp ik het zo goed?

[__fred__]

Md5 is insecure.

[Haan]

__fred__ schreef op zaterdag 9 februari 2019 @ 17:10:
Md5 is insecure.

Voor wachtwoord hashes ja, voor een file hash kan je het prima gebruiken.

[__fred__]

Haan schreef op zaterdag 9 februari 2019 @ 20:03:
[...]

Voor wachtwoord hashes ja, voor een file hash kan je het prima gebruiken.

Nee, als de “aanvaller” controle heeft over de inhoud van een document, kan hij altijd een bepaalde hash genereren, gegeven dat het bestandsformaat wat ruimte heeft voor willekeurige tekens.

Md5 is goed genoeg voor controleren op datacorruptie of andere niet moedwillige wijzigingen, niet voor moedwillige aanpassingen. File of wachtwoord maakt niet uit.

[Glewellyn]

Ik begrijp wat je wil bereiken, maar je focust te veel op techniek en te weinig op concept. Bedenk eerst goed hoe dit conceptueel zou moeten werken, daarna zoek je pas een passende techniek.

Jouw probleem:
Iemand met voldoende kennis en doorzettingsvermogen zal altijd om de encryptie heen kunnen werken. Uiteindelijk verstrek je iemand namelijk zowel de gecrypte content, het decryptie-algoritme, als de sleutel om te decrypten.

Encryptie is bedoeld om derden geen toegang te geven tot geheime berichten. Je kan niet iemand toegang geven tot data zonder hem toegang te geven tot die data. Een kopie van die ontsleutelde data is altijd te maken en te wijzigen door de ontvanger.

[ Voor 15% gewijzigd door Glewellyn op 09-02-2019 22:38 ]

[.oisyn]

__fred__ schreef op zaterdag 9 februari 2019 @ 22:21:
niet voor moedwillige aanpassingen. File of wachtwoord maakt niet uit.

Ik wil dit even nuanceren. MD5 is idd voor beide onveilig, maar niet om dezelfde reden.

Het is onveilig voor signing omdat je makkelijk collisions kunt genereren. Het is onveilig voor passwords omdat het snel te bruteforcen is.

[__fred__]

.oisyn schreef op zaterdag 9 februari 2019 @ 22:40:
[...]


Ik wil dit even nuanceren. MD5 is idd voor beide onveilig, maar niet om dezelfde reden.

Het is onveilig voor signing omdat je makkelijk collisions kunt genereren. Het is onveilig voor passwords omdat het snel te bruteforcen is.

En ook dat is weer te nuanceren, omdat het afhangt van het doel: Wil je inloggen in het systeem waar de md5 hash uitkomt, dan is het tegenwoordig sneller om een collision te berekenen (al is ie gemiddeld 1024 bits lang, dus je moet wel wat ruimte krijgen van het systeem voor het invoeren van een lang wachtwoord.)

Wil je het waarschijnlijke wachtwoord achterhalen voor het inloggen van dezelfde user op een andere sites (als hij /zij hetzelfde wachtwoord hergebruikt) dan is een dictionary attack of bruteforce logischer.

Evengoed gebruikt de TS beter iets dat ervoor bedoeld is, en vind je niet het wiel opnieuw uit. HMAC is ervoor bedoeld. Als je het dan toch hebt over veilig gebruik van md5 bij authenticatie. HMAC md5 is wel veilig door de dubbele hashing en vaste structuur van het bericht.