Servus! Folgende Aufgabenstellung: Ich habe ein sicheres (Im Sinne von Manipulations-/Abhör-/Einbruchssicher) System A. Dieses System A liest Meßwerte aus und schreibt diese mit einem Schlüssel A verschlüsselt auf einen Datenträger. Dieser Datenträger soll nun weitergegeben werden können und die darauf befindlichen Daten mit einem Schlüssel B ausgelesen werden können. Ein Benutzer soll aber mit dem Schlüssel B nicht in der Lage sein (manipulierte, verschlüsselte) Daten wieder auf den Datenträger zu schreiben. Umgekehrte asymetrische Verschlüsselung sozusagen. Ist sowas prinzipiell möglich ? - Ich denke ja. Kennt mir jemand Suchbegriffe nennen mit denen ich mehr Infos bekomme, bzw. Realierungstips? - Eventuell gibt es ja bereits opensourcetools mit denen das möglich ist. Danke, Erwin
Erwin Witt schrieb: > Ist sowas prinzipiell möglich ? - Ich denke ja. nein, aber das ist doch auch egal. Wenn B selber veschlüsselt dann steht drin das es B war. Du musst also nur Prüfen ob es von A verschlüsselt ist - nur das ist gültig.
Abgesehen von Verschlüsselung ist die Grundanforderung verwandt mit der Forderung nach nicht modifizierbarer Archivierung, siehe WORM. Dafür gibt es fertige Lösungen, die sicherlich auch mit Verschlüsselung ausgestattet werden können. Vielleicht hilft dir das weiter.
Ich würde das in 2 Schritte aufteilen: 1. A signiert die Daten mit seinen privaten Schlüssel 2. A verschlüsselt die Daten mit Bs öffentlichen Schlüsssel
?? genau das macht doch PGP (oder per Cert verschlüsselte e-mails) man verschlüsselt eine e-mail, und nur der Empfänger (und man selber) kann sie lesen.. und der Empfänger kann natürlich selber nicht damit verschlüsseln deshalb ja "private-public" key usw. und wie " Verwirrter Anfänger " schrieb, selber signieren muss man sie noch, damit der absender klar ist..
Robert L. schrieb: > und der Empfänger kann natürlich selber nicht damit verschlüsseln klar kann er, weil er einen Private key hat, sonst könnte er ja nicht entschlüsseln. Und mit einem Private Key kann man auch verschlüsseln.
Peter II schrieb: > Und mit einem Private Key kann man auch verschlüsseln. Man verschlüsselt aber mit dem public Key des Empfängers.
Und signiert mit dem eigenen private key. Die Signatur ist der Schlüssel zur Authentifizierung des Absenders, nicht die Verschlüsselung. Und die sollte sich hier ebenfalls nutzen lassen. Die Verschlüsselung, soweit in der Sache überhaupt notwendig, ist dann nur ein Nebeneffekt.
@ Alle, danke für euere Inputs. Jetzt weiß ich,dass das was ich Suche ist eine Digitale Signatur ist...
Ulf H. schrieb: > Peter II schrieb: >> Und mit einem Private Key kann man auch verschlüsseln. > > Man verschlüsselt aber mit dem public Key des Empfängers. genau und B kenn ja wohl seinen Public key - damit kann er es auch neu veschlüsseln. Verschlüsselung ist hier nebensache, es geht um einen Unterschrift(Signatur) und da muss nur geprüft werden ob A das dokument unterschireben hat - fertig.
Ulf H. schrieb: > Peter II schrieb: >> Und mit einem Private Key kann man auch verschlüsseln. > > Man verschlüsselt aber mit dem public Key des Empfängers. Ja, aber man kann bei symmetrischen Algorithmen dafür versehentlich oder absichtlich auch den Private Key nehmen. Dann lässt sich mit dem Public Key entschlüsseln - d.h. jeder kann entschlüsseln.
Das ist dann ein reiner Signaturmechanismus. Wenn die Daten klein genug ist, ist das unproblematisch. Für grössere Daten sollte man bedenken, dass Hashverfahren (MD5&Co) mit asymmetrischer Verschlüsselung des Hashs wesentlich anspruchsloser sind, als die recht rechenintensive asymmetrische Verschlüsselung der kompletten Daten.
> als die recht rechenintensive >asymmetrische Verschlüsselung der kompletten Daten. macht "man" doch sowieso nicht!? sonst könnte man die e-mail ja nicht mal selber lesen..?? bzw. zumindest könnte man nicht eine e-mail an mehrere Empfänger schicken: http://de.wikipedia.org/wiki/Pretty_Good_Privacy
Robert L. schrieb: > bzw. zumindest könnte man nicht eine e-mail an mehrere Empfänger > schicken: Wenn du die kompletten Daten mit einem eigenen privaten Schlüssel "verschlüsselst", dann kann jeder es mit deinem öffentlichen Schlüssel entschlüsseln. Sogar du selbst. Das ist dann eine reine Signatur.
>Wenn du die kompletten Daten mit einem eigenen privaten Schlüssel >"verschlüsselst", warum (und vor allem WIE) macht man das ? (ich hab extra von E-Mail gesprochen,..)
Wie: Nicht mit PGP. Ich meinte das Verfahren, nicht das Programm. Mit PGP geht man dafür den üblichen Weg und signiert ohne zu verschlüsseln. Technisch ist das der beschriebene Weg eines so verschüsselten Hashs.
So, ich habe in der Zwischenzeit etwas mehr über Hashes (MD5, SHA), Asymetrische Kryptographische Verfahren recherchiert. So will ich es angehen: Signieren "Daten(1GB)" --SHA1--> "HASH" --RSA(private key)--> "verschlüsselter Hash" Verifizieren: "verschlüsselter Hash" --RSA-public key--> "Hash" == "entschlüsselter Hash"? Soweit ich es verstanden habe ist die Sicherheit der Verifikation in diesem Fall nur vom asymetrischen Verfahren abhängig. Bei Verwendung von RSA also von der Schlüssellänge. Der Hash wird nur benötigt um die zu verschlüsselnde Datenmenge klein zu halten. 1024bit RSA sollten für die nächsten 5 Jahre sicher sein.
Erwin Witt schrieb: > Soweit ich es verstanden habe ist die Sicherheit der Verifikation in > diesem Fall nur vom asymetrischen Verfahren abhängig. Bei Verwendung von > RSA also von der Schlüssellänge. Der Hash wird nur benötigt um die zu > verschlüsselnde Datenmenge klein zu halten. 1024bit RSA sollten für die > nächsten 5 Jahre sicher sein. nicht nach Deutschen Signatur gesetzt: http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/BNetzA/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/2012Algorithmenkatalog.pdf?__blob=publicationFile sha1 ist schon nicht mehr zugelassen, mindestens sha256 sollte du verwenden. und auch rsa mit 1024 ist schon drausen, 2048 wird empfohlen.
Aus welchem Grund sollte der Hash eine Auswirkung auf die Sicherheit der Signatur haben? Ich benuütze den Hash ja nur um die Datenmenge die ich asymetrisch Verschlüsseln muss zu reduzieren. Würde ich die Daten mit RSA verschlüsseln, und zum Verifizieren die mit dem public Key entschlüsselten Daten mit den erhaltenen Daten vergleichen würde das aufs Gleiche kommen. Oder übersehe ich da was?
Erwin Witt schrieb: > Aus welchem Grund sollte der Hash eine Auswirkung auf die Sicherheit der > Signatur haben? der Hash ist so kurz, das man es schon (fast) schafft einen Datei zu erzeugen die einen anderen Inhalt hat aber den gleichen Hash. Warum ist der Hash wohl nicht nur 1byte lang?
Stimmt schon jedoch, finde jedoch auch Daten die einen Sinn ergeben und den gleichen Hash haben...
Erwin Witt schrieb: > Stimmt schon jedoch, finde jedoch auch Daten die einen Sinn ergeben und > den gleichen Hash haben... das ist aber mit SHA-1 (oder gar MD5) z.b. deutlich einfacher als mit moderneren algos. SHA-1 erlaubt "abkürzungen", man muss also nicht alle möglichen werte durchprobieren bis mal was passt sondern kann gezielter suchen.
@ __tom Und? Wo liegt das Problem. Dann kann ich halt vom Hash auf die Daten schließen. - Die Daten liegen sowieso vor und sind kein Geheimnis. Das sind ja die Daten die ich signieren will.
Der wichtige Aspekt am Hash ist: Es darf nicht möglich sein, mit vertretbarem Aufwand ein Datenfile zu produzieren, dass einem gegebenen Hashwert entspricht.
Kann ich ja beim verschlüsseln von Passwörtern verstehen aber warum bei dieser Anwendung. Wie gesagt: Geg.: Daten die von Gerät A zu Gerät B über einen Datenträger transferiert werden. Ges.: Ein Weg herauszufinden ob diese Daten am weg dorthin manipuliert wurden. Lösung: Daten mit RSA(privat) kodieren. Auf den Datenträger sowohl die codierten als auch die decodierten Daten schreiben Verifikation Daten mit RSA(public) decodieren. Selbst decodierte Daten mit decodierten Daten vom Datenträger vergleichen. Sind sie gleich wurde nicht manipuliert. Alternative: Nicht die Daten selbst vergleichen sondern einen Hash dieser Daten, da der Hash kleiner ist und somit weniger lang zum codieren braucht. Falls es Daten gibt die einen gleichen Hash ergeben ist das egal, weil die Daten (die ja die eigentliche Nachricht ist und einen Sinn ergeben muss) keinen Sinn ergeben werden.
Erwin Witt schrieb: > Falls es Daten gibt die einen gleichen Hash ergeben ist das egal, weil > die Daten (die ja die eigentliche Nachricht ist und einen Sinn ergeben > muss) keinen Sinn ergeben werden. Die Struktur der Daten ist natürlich eine weitere implizite Sicherheit. Nur ist die schlecht als allgemeine Eigenschaft von solchen Algorithmen einschätzbar, weshalb deren Beurteilung sich darauf nicht verlassen kann. Ob dir ein heute bereits als nicht mehr sicher geltender Hash-Algorithmus reicht musst du selbst entscheiden. Willst du persönlich die Sicherheit gegen Manipulation, oder muss sie auch von dritter Seite anerkannt werden?
Ja, es soll von dritter Seite anerkannt werden. Sprich von einem Kunden. Falls ich die Sicherheit argumentieren kann und das glaube ich mit obigen Argument zu können wird dies so passen. In (m)einem System gibt es ganz andere Schachstellen die wesentlich wahrscheinlicher sind. z.B.: Einbruch in die Anlage die die Daten aufzeichnet und mit dem private Key signiert. --> private Key Diebstahl. etc.
Erwin Witt schrieb: > Ja, es soll von dritter Seite anerkannt werden. Sprich von einem Kunden. > Falls ich die Sicherheit argumentieren kann und das glaube ich mit > obigen Argument zu können wird dies so passen. das wird schwer. Ich würde es nicht anerkennen weil es ja die oben verlinkte dokumente der Bundesnetzagentur kenne? Warum nicht einfach auf SHA256 und 2048bit RSA setzen und damit sogar den offizellen vorgaben entsprechen?
SHA256 brauch ca. 75% länger auf meiner Maschine (Cortex M8) als SHA1. SHA1 bei 1GB bereits 1 Minute. Möchte dem Benutzer unnötige Wartezeiten ersparen.
Futter schrieb: > SHA256 brauch ca. 75% länger auf meiner Maschine (Cortex M8) als SHA1. schlechter code? eine kurze suche zeigt folgende Zahlen: http://www.cryptopp.com/benchmarks.html SHA-1 153 SHA-256 111 also nur 40% mehr > SHA1 bei 1GB bereits 1 Minute. kommt mir gefühlt sehr langsam vor ich haben irgendwo gelesen 20Takte pro byte. Das sind dann nur 17Sekunden bei 600Mhz - wo verbingst du den resst der zeit?
Genauer gesagt wird ein AM3359 eingesetzt. Die Hashes habe ich mit openssl generiert. Ich wollte mal nur Anhaltspunkte haben wie lange das ganze ca. braucht. Momentan rennt nix parallel. (Ausser irgendwelche idle Betriebssystemprozesse) Apropos, danke für den Link zu dieser Library!
Erwin Witt schrieb: > Genauer gesagt wird ein AM3359 eingesetzt. dann solltest du auch die hardware richtig nutzen, glaube kaum das openssl das macht. Crypto Hardware Accelerators (AES, SHA, – General-Purpose Memory Controller (GPMC) PKA, RNG)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.