Wie convertiere ich einen pkcs8 key in einen java lesbaren?

[Thallius]

Hi,

ich habe für meien php scripte einen pkcs8 key im uncrypted format. Also ein textfile ala

-----BEGIN PRIVATE KEY-----
....
-----END PRIVATE KEY-----

Diesen key möchte ich nun gerne in java auch benutzen. Java verlangt den key aber irgendwie in einem anderen format damit ich ihn mit

ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream(file));
rsaKey = (PublicKey) inputStream.readObject();
inputStream.close();

einlesen und dann mit Cipher benutzen kann.

Wie konvertiere ich das?

Danke

Claus

 

[tommysenf]

Was du dort versuchst ist einfach den Java Objektserialisierungsmechanismus zu verwenden. Das kann so natürlich nicht funktionieren, da dein File kein serialisiertes Java Objekt enthält.

Hier findest du ein Beispiel zum Laden eines PKCS8 Keys mit Java:
http://juliusdavies.ca/commons-ssl/pkcs8.html

Eventuell sind auch diese Grundlagentutorials für dich interessant:
https://docs.oracle.com/javase/tutorial/security/apisign/index.html
https://docs.oracle.com/javase/8/docs/technotes/guides/serialization/

 

[mrBrown]

Na das das, was du da versuchst nicht klappt ist doch klar...

Ich würde mal behaupten, die Datei als byte-Array einlesen und eine der entsprechenden Factory-Methoden nutzen...

 

[Thallius]

Was du dort versuchst ist einfach den Java Objektserialisierungsmechanismus zu verwenden. Das kann so natürlich nicht funktionieren, da dein File kein serialisiertes Java Objekt enthält.

Hier findest du ein Beispiel zum Laden eines PKCS8 Keys mit Java:
http://juliusdavies.ca/commons-ssl/pkcs8.html

Eventuell sind auch diese Grundlagentutorials für dich interessant:
https://docs.oracle.com/javase/tutorial/security/apisign/index.html
https://docs.oracle.com/javase/8/docs/technotes/guides/serialization/

Oh Mann Danke. Wie blöd muss man sein. Ich habe mindestens 2 Stunden auf den Code geschaut und den Fehler nicht gesehen. Manchmal sollte man einfach aufhören wenn die konzentration nicht mehr da ist.

Claus

 

[Tobse]

Ich weiss, ich trete da immer jemand auf den Schlips mit sowas, aber: die Wahrscheinlichkeit, dass du auf diese Ebene wirklich selbst runter musst, geht gegen 0. Es sollte doch genügen, der Library, die damit arbeiten soll (TLS, whatever) den Pfad zum Keyfile zu geben. Von Cipher ganz zu schweigen...

 

[Thallius]

Ich weiss, ich trete da immer jemand auf den Schlips mit sowas, aber: die Wahrscheinlichkeit, dass du auf diese Ebene wirklich selbst runter musst, geht gegen 0. Es sollte doch genügen, der Library, die damit arbeiten soll (TLS, whatever) den Pfad zum Keyfile zu geben. Von Cipher ganz zu schweigen...

Gut vielleicht hast du ja eine bessere Idee.

Es geht darum, dass sensible Daten auf einem "öffentlichen" Webserver gespeichert werden sollen. Dabei dürfen alle Clients dort Daten speichern aber nur einige wenige diese lesen.
Meine Idee war deswegen, alle Daten die zu dem Server gehen mit dem pub key zu crypten.
Damit kann der Server gerne gehackt werden, da er selber nicht im Besitz des priv keys ist kann er und damit auch der Hacker die Daten nicht entschlüsseln. Selbes gilt für alle Clients die nur mit dem pub key ausgeliefert werden. Nur die Clients, welche auch den priv key bekommen können die Daten dann auswerten.

Gruß

Claus

 

[Tobse]

Dafür ist Kryptographie ein absolut valider Anwendungsfall - aber man muss nicht selbst mit dem Cipher hantieren dafür. Da gibts auch viel, was man falsch machen kann.

Ich persönlich würde ein Tool wie GnuPG in die Anwendung einbetten und das mit ProcessBuilder aufrufen. Dann kannst du PGP-Verschlüsselte Dateien verwenden, bekommst eine auf Herz- und Nieren geprüfte und getestete Implementierung der gesamten Kryptographie - und musst in deiner Anwendung im Prinzip nur einen Shell-Befehl absetzen.
GnuPG kann man auch für Windows kompilieren - ist also kein Problem. Obendrein benutzt du dann ein Standardardisiertes Protokoll.

Dazu kommt ja, dass JVMs von Haus aus nur AES-128 und SHA-1 untersetützen müssen (siehe Javadoc zu Cipher und MessageDigest). Damit kommt man nicht weit.

 

[AndyJ]

Hi,

dazu solltest du folgendes wissen:

Der key im Format

-----BEGIN PRIVATE KEY-----
....
-----END PRIVATE KEY-----

ist Base64 encoded. Den String zwischen den beiden Zeilen musst du also erstmal decoden. Was du dann hast ist die binaere Version einer ASN.1 Datenstruktur:

PrivateKeyInfo ::= SEQUENCE {
   version Version,
   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
   privateKey PrivateKey,
   attributes [0] IMPLICIT Attributes OPTIONAL }

 Version ::= INTEGER

 PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

 PrivateKey ::= OCTET STRING

 Attributes ::= SET OF Attribute

ASN.1 steht fuer Abstract Syntax Notation One, eine Sprache mit der Datenstrukturen sprachunabhaengig beschrieben werden. Die so beschriebene Datenstruktur muss dann natuerlich in ein Binaerformat ueberfuehrt werden. Dazu gibt es verschiedene Encodings, e.g. DER, BER, etc.. Fast alles was mit Kryptographie zu tun hat ist DER encoded (DER = Distinguished Encoding Rules).

In Java gibt es einige Klassen, die dir damit helfen. Dia API ist bekannt als JCA/JCE (Java Cryptograpy Architecture/Java Cryptography Extensions). Schau dir mal diese Klasse an:

java.security.spec.PKCS8EncodedKeySpec

Java bietet allerdings nicht wirklich viel. Die Bouncycastle Library ist ideal fuer deinen Zweck: http://bouncycastle.org/

Du solltest keine Scheu haben, mit Kryptographie zu arbeiten. Ist ein interessantes Feld und man kann eine Menge lernen. Viel Spass!

Cheers,
Andy

 

[AndyJ]

Hier noch ein Link zu ASN.1 http://www.oss.com/asn1/resources/asn1-made-simple/introduction.html
Auf der Seite gibt's auch ein kostenloses Buch dazu.

 

[Tobse]

Du solltest keine Scheu haben, mit Kryptographie zu arbeiten. Ist ein interessantes Feld und man kann eine Menge lernen.

Scheu vor Kryptographie ist in der Tat nicht gut. Ein proprietäres Protokoll ist aber genauso unangebracht. Die erste und wichtigste Regel der Kryptographie ist: Never Roll your own crypto.

Damit rumzuspielen ist super interessant und das habe ich auch schon ausführlich gemacht. Aber diesen Code dann produktiv zu verwenden ist grob Fahrlässig. Wenn eine Lücke drin ist und deswegen Daten geklaut werden, ist das geheule dann groß.

Siehe diesen Post auf SecuritySE zum Thema custom security:
https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own

Es ist immer hilfreich, sich mal die Crypto-Sicherheitslücken anzusehen, die so gefunden werden. Das sind keine gewöhnlichen Bugs. Gerade wenn es um Timing-Angriffe und Memory-Leaks geht merkt man, wie super einfach man einen riesen Fehler machen kann, wenn man solchen Code selbst schreibt.
Z.B. muss man in Java wegen der Garbage-Collection alle sensiblen Daten ausschließlich in byte[]s halten, damit man sie nach getaner Arbeit zuverlässig aus dem RAM löschen kann.

 

[AndyJ]

Der Original-Poster hat doch gar nicht versucht seine eigene Krypto zu erfinden - er will nutzen was schon da ist. Manchmal denke ich mir, die Warnung nur ja nichts selbst mit Krypto zu machen ist eine Erfindung der NSA. Hat sie doch effektiv verhindert, dass sich Softwareentwickler ueberhaupt mit dem Thema befassen - und das schon mehr als ein Jahrzehnt. Deswegen ist der Stand der Dinge in Hinsicht auf Security so scheisse und die Geheimdienste haben leichtes Spiel...

Cheers,
Andy

Das hier ist doch ein Forum, das Wissen vermitteln soll. Also weg mit solchen Warnungen. Besser waere es einen Forenbereich einzurichten, wo wir den Code anderer reviewen koennen. Wie waer's damit?

 

[Tobse]

Ich sage ja auch nicht, dass man sich nicht damit auseinandersetzen soll. Um sich das Wissen anzueignen, ist es auf jeden Fall hilfreich, das alles mal selbst implementiert zu haben, auch so low-level, die Crypto-Algorithmen selbst zu implementieren.

ABER: @Thallius arbeitet meist an teuren Projekten für Unternehmen - zumindest sagt er das. Und in diesem Umfeld ist eigens geschriebener Code (auch wenn er von 10-15 Leuten reviewt wurde) grob Fahrlässig, wenn man Zugriff auf Implementierungen hat, die von Tausenden Geprüft wurden und welche den Attacken der Größten Regierungen der Welt standhalten: die verfügbaren Open-Source implementierungen von PGP, TLS und OTR.
Wenn man das Thema beruflich betreiben möchte kann man Mathematik studieren, sich auf Cryptographie spezialisieren und dann an diesen Open-Source Projekten teilnehmen.

----
Bei Kryptographie stehen teils Menschenleben auf dem Spiel. Man blicke nur in die Türkei und auf die Journalisten dort. Diese Menschen sind auf gute Kryptographie angewiesen. Und sie haben nicht das Fachwissen, Code zu prüfen. Sie müssen sich darauf verlassen. Diesen Menschen gegenüber wäre es IMHO Respektlos, ihnen eine vglw. nicht bis minimal getestete Software als gleich sicher wie eine Millionenfach als sicher befundene Software zu verkaufen.

Analoges Beispiel: Du kennst vielleicht jemand, der gerne an Autos bastelt. Sagen wir, so einer nimmt einen alten Käfer auseinander und baut ihn wieder zusammen. Er hat kein eigenes Auto entworfen, wohl aber hat er es selbst montiert.
Du musst jetzt im Winter 5000km per Autoo zurücklegen und hast die Wahl zwischen dem selbst montierten Käfer deines Kumpels und einem Mietwagen eines Namhaften Autoherstellers (sagen wir ein VW Passat von 2016). Probefahrt nicht erlaubt, mit keinem von beidem. Was wählst du?

 

[AndyJ]

[QUOTE="..., wenn man Zugriff auf Implementierungen hat, die von Tausenden Geprüft wurden und welche den Attacken der Größten Regierungen der Welt standhalten: die verfügbaren Open-Source implementierungen von PGP, TLS und OTR....[/QUOTE]

Heartbleed anyone? Und etwas mehr Selbstvertrauen bitte.

 

[Thallius]

@Tobse

Ich gebe Dir generell recht. Nur wer sagt mir, dass nicht gerade diese 1000fach getesteten Frameworks eine Backdoor für die NSA, BND, MI6, Goole, Microsoft, Apple oder wen auch immer haben? Also ganz sooo blauäugig wäre ich da vielleicht doch nicht.

Gruß

Claus

 

[Tobse]

@AndyJ ja, es gab Heartbleed; die OS Libraries sind sicher nicht perfekt. Willst du mir sagen, dass du so einen Fehler nie machen würdest? Hättest du Heartbleed finden können?

Ich kenne deine Skills nicht, ich beurteile dich nicht. Ich vermute du bist genauso wenig ein Super Computergenie wie ich oder diejenigen, die Fehler wie Heartbleed, Goto-Fail oder Stagefright machten. In den 1000en Zeilen Code, welche für TLS nötig sind, ist sehr viel Platz und Gelegenheit für solche Fehler.

Selbst Crypto-Koriphäen wie Bruce Schneier machen schwere Fehler. Und die werden nur gefunden, weil unzählige Leute den Cose reviewen, testen, und versuchen, ihn zu knacken.

Auch wenn die Standard-Libs nicht perfekt sind, sind sie IMHO die sicherste Option, ausser

@Thallius
Wenn du dir da ernsthaft Sorgen drum machst, kann es IMO schon sinnvoll sein, etwas eigenes zu Coden. Es ist wohl gleich schwierig eine Backdoor zu finden (vllt sogar schwieriger), als eine solide Implementierung selbst zu schreiben. Das aber mit dem o.g. Risiko, Lücken drin zu haben, die sich nur durch Geheimhaltung des Codes nicht ausgenutzt werden können.

Am Ende des Tages muss man jemandem Vertrauen; die zugrundeliegenden Algorithmen kann man ohne langes Studium der Mathematik vmtl nicht prüfen

 

[JStein52]

die zugrundeliegenden Algorithmen kann man ohne langes Studium der Mathematik vmtl nicht prüfen

Er hat kein eigenes Auto entworfen, wohl aber hat er es selbst montiert.

Irgendwie hat sich das Thema wohl verselbstständigt. @Thallius wollte doch weder eigene Algorithmen entwickeln noch wollte er ein Auto montieren. Er wollte sein Gepäck reinlegen, den Zündschlüssel nehmen und losfahren. Und er wollte nur den richtigen Weg wissen

 

[Tobse]

Er wollte sein Gepäck reinlegen, den Zündschlüssel nehmen und losfahren. Und er wollte nur den richtigen Weg wissen

Ich hatte das anders verstanden, weil er den Schlüssel selbst parsen und dann selbst mit einem javax.crypto.Cipher verwendetn wollte. Ein einzelner aufruf an ein PGP-Binary zum Ver- und Entschlüssen wäre für mein Verständnis "Gepäck in den Mietwagen legen und losfahren"