 Hi, oder moin moin, ich bin Dominik und seit dem Endumen-Studiums arbeite ich in der Software-Entwicklung und in dem Zusammenhang habe ich mich mit RSA-Verschlüsselung auseinander gesetzt und habe euch was mitgebracht zwischen Android, iOS und Java. Schauen wir mal. Fertil Success oder vielleicht sollten wir Fatal Until Success das Ganze nennen, wenn wir hier nicht durchkommen, dann brauchen wir es nicht weiter benutzen, denn eine halbe Security hilft uns nicht. Ich möchte erst ein bisschen der Warnungsmanagement betreiben. Die folgenden Grundlagen sehe ich als bisschen Voraussetzung und zwar die Unterscheidungen zwischen isometrischer und isometrischer Verschlüsselung. Ich denke aber, dass ich flach genug bleibe, dass das alles funktioniert. Und in dem Zusammenhang RSA, der Riverrest Charmy Adleman, ist ein isometrisches Verschlüsselungsverfahren und dementsprechend haben wir ein Public Private Key, also zwei Keys, mit denen wir arbeiten. Ansonsten, es handelt sich um eine Geschichte im Software-Entwicklungsprozess, also ich werde nicht allzu viel Programmiercode zeigen, aber ein klein wenig. Mathematische Tiefe werden wir wahrscheinlich eher vermissen. Logikatter, Bitflipping etc., das lassen wir heute einfach mal weg. Und Taschenrechner werden nicht benötigt, voraussichtlich, voraussichtlich. Eine weitere Sache, Disclaimer. Hier waren mehrere Personen beteiligt. Dementsprechend habe ich euch ein paar Bargäne mitgebracht, beziehungsweise im Laufe des Vortrags mehrere. Für Emotionen, für Kollegen, mit denen man sich bespricht. Und ich habe euch noch eine Gummienthe mitgebracht für Rubber Duck Developing. Wenn wir also nicht mehr weiterkommen, erklären wir mal ein bisschen das Problem und manchmal löst sich das von alleine. Ansonsten haben wir eine klassische inkrementelle Entwicklung. Wir programmieren unter Annahmen, laufen gegen Fehler, finden Lösungen und machen das in der Schleife, bis es irgendwie funktioniert und wie jemand im Code Review sagt, dass das alles noch nicht so schön aussieht, wie es könnte. Also ganz professionell. Ansonsten hier ist wirklich der Fokus auf RSA. Wir lassen die elliptischen Kurven komplett raus. Hier sind Out of Scope, wir waren uns heute nicht mit beschäftigen. Des Weiteren, wenn wir Programmiercode sehen, ist der für den Vortrag aufbereitet. Das Ziel ist Verständlichkeit und das ist die Superschönheit, dass so, wie man sie hinterher auch, ja, weiter nach draußen bringen würde. Und die Bilder sind letztendlich mit deligeneriert. Wenn ihr aus diesem Vortrag irgendwas mitnimmt, nutzt gut dokumentierte Cryptolibraries oder Don't Roll Your Own Crypto. Ansonsten, Setting. Was machen wir? Wir gehen davon auf. Eine größere Freundesgruppe möchte sich regelmäßig verabreden. Alle Beteiligten sitzen mobile Endgeräte, iOS, Android. Die Termine werden aus Gründen von einem Individuum festgelegt und die äußeren Umstände verlangen, dass die Termine auf einem einzelnen Server abgelegt werden und die mobilen Endgeräte holen diese Termine, also quasi den Klartext von diesem Gerät ab. Das ist das, was wir sicher transportieren wollen. Die Termine sollen nicht frei im Internet rumschwirren. Die Freunde sind ansonsten programmier-affin und mögen ihre mobilen Apps in ihrem eigenen Style. Es kann schon mal sein, dass sie dieses andere Kollegen nicht mögen oder lieber einen Rotsteller in Grün haben wollen und so programmieren sie gegen die Schnittstelle, die wir bereitstellen. Es kann sein, dass wir mehrere Apps haben unter Android oder iOS. Zuletzt, wir vernachlässigen bewusst Authentifizierung und Autorisierung. Das ist hier erst mal nicht weiter im Fokus. So Aufbau des Systems. Was können wir denn da, wie können wir uns das Ganze vorstellen? Zuerst krevi- irren wir ein Schlüsselpaar, sowohl bei iOS, Android und das soll dann über die Leitung gehen, also zumindest der Public Key, der Private in Schwarz bleibt bei uns und der ist weiterhin verdeckt quasi. Auf der anderen Seite steht ein Java Service, der verschlüsselt payload-Klartext und mit dem Public Key und wenn das geschehen ist, haben wir einen Ciphertext. Der geht wieder zurück über die Leitung und letztendlich mit dem Private Key können wir das Ganze wieder entschlüsseln. Durch den Vortrag hindurch werden die Public Keys unterstrichen sein und die Private Keys fett markiert. Der Ciphertext ist verschlüsselt und deshalb durchgestrichen und etwas schwerer lesbar. Jetzt kommt die Frage so und das, was wir uns dafür gerade vorstellen, ist das miteinander kompatibel? RSA-Verschlüsselungen gibt es schon ein bisschen länger, 1977 haben wir Hoffnungen und für Java selbst gibt es eine schöne Library, Java X-Krypto können wir benutzen. Bei Android geht das genauso. Allerdings wollen wir die Keys nicht unbedingt zack auf unsere Platte schreiben und dann liegen die da ungeschützt rum und irgendwelche anderen Apps können genauso drauf zugreifen wie wenn man Fotos einer App bereitstellt. Deshalb schauen wir Android Key Store. Das wird auch eine schöne Sache, die in dem gibt es seit dem AP Level 18. Man erinnert sich Jellybean 2013 ist schon ein bisschen was her. Kriegen wir damit die meisten Android-Geräte, die gerade so rumschwirren, abgedeckt. Jawohl, 99 Prozent, super gut. Das ist schon mal eine schöne Sache. Wie sieht es bei iOS aus? Kann das auch. Die Dokumentation alter Funktionen verfällt, klassische Deplication und ein Nachhalten der Funktionalität ist schwierig. Alles in allem können wir sagen passt. Gibt richtig schönen Daumen nach oben, wobei der ist. Er hat noch einen kleinen Knick. Es könnte sein, dass wir da vielleicht noch mal nachschärfen müssen, wie gut der Daumen nach oben geht. Zuerst wollen wir uns aber um Performance kümmern. Wir wollen ja, dass die Nachrichten schnell bei uns ankommen. Also wie sieht es mit der Performance von RSA aus bei verschiedenen Schlüssel-Längen? Wir befinden uns noch vor der Entwicklung und deshalb suchen wir nach einer Nährung. Was gibt es denn da? Wir machen ein bisschen Programmiermagic, also kurz, wir gehen in die Shell, in den Terminal, geben einmal OpenSSL Speed ein mit verschiedenen Schlüssel-Längen 1024, 2048, 4096. Was dann passiert? Für alle drei Schlüssel-Längen wird einmal etwas signiert und danach geprüft, ob diese Signatur passt. Jeweils werden für die drei Durchgänge mit beiden Richtungen zehn Sekunden dem System gegeben und am Ende kommt raus, wie viele Signaturen pro Sekunde geschafft wurden. Wenn wir uns das also in der schönen Grafik angucken, sehen wir auf der rechten Seite, dass eine Schlüssel-Länge der linke Balken von 1024, da kriegen wir innerhalb der zehn Sekunden sehr viele Signaturen bzw. Verifies pro Sekunde hin und wenn die Schlüssel-Längen länger werden, dauert es bedeutend länger, das Ganze durchzuführen. Wir können ganz grob abschätzen, nur durch eine Verdoppelung der Schlüssel-Länge sind wir noch nicht mal die Hälfte an Geschwindigkeit, sondern weniger. Es ist also richtig teuer, wenn wir lange Schlüssel-Längen benutzen. Das ist das, was wir hinwenden wollen. Es ist teuer, lange Schlüssel-Längen zu benutzen. Dann schauen wir auf die andere Seite ein bisschen Dokumentation lesen. Was ist denn notwendig, wenn wir das sicher geschalten wollen? Das BSI sagt, übergangsweise bleibt eine Schlüssel-Länge von größer 2000 Bit für S.A. Schlüssel bis Ende 23 conform. Ab 2024 sind größer 3000 Bit verbindlich. Okay, wenn wir das jetzt gerade implementieren, dann wollen wir ja conform sein und zwar auch über den Ende des Jahres 2023 hinaus. Also sind wir mal generös und werden im Nachgang einfach mit 4096 arbeiten. Schauen wir mal. Wie sieht es denn bei den gegebenen Systemen aus? Wir machen 4096, schauen uns die Dokumentation an und Android sagt ja, explizit, woher 2048 schaffen wir und mehr geht auch, aber sagen wir nicht so, explizit. Als Gleiches bei iOS. Ich gebe zu, ich war etwas verdutzt, dass das BSI hier die Abongat in der Hinsicht darstellt. Aber ich bin froh, dass das so ist und dann können wir einfach weitermarschieren. Also vorgehen im Java Microservice. Wir sind also auf der rechten Seite des Systems beschreibenden Test. Wir stellen ein Schlüsselpaar, verschlüsseln das Ganze und entschlüsseln. Also Achtung, Code. Sehen wir hier ein bisschen was und das geht mir in erster Linie um die obere Hälfte. Da haben wir so ein paar Zeilen und unten drunter gibt es ganz viel, was daneben gehen kann. Es geht gar nicht darum, was kaputt geht, aber es geht darum, da kann ganz schön viel schief gehen. Also offizielle Cryptolibraries benutzen. Aber alles in allen, das funktioniert und Microservice haben wir abgehakt. Top. Also in der Gesamtsicht haben wir hier schon mal eine Haken hinter. Das ist richtig schön und es geht weiter mit dem Senden des Public Keys und dem Empfang des Ciphertext. Wie machen wir das? Gängige Praxis kommt jetzt gleich. Wir haben den Public Key generiert. Der ist ein Array aus Bits und könnte dann so aussehen. Das ist jetzt nicht so gut lesbar und wenn wir das mal rauskopieren, vergleichen wollen in irgendeinem String Matcher, so lange noch in der Entwicklungs-Kontext sind, können wir es zu Problemen führen. Also können wir das Ganze auch Base64 encoden und damit besser weiterarbeiten. Also wenn wir wirklich mal Fragen haben, was wir gerade so sehen oder nicht sehen, damit kriegen wir mit, ob das, was wir bei iOS oder Android losgeschickt haben, auch genauso in Microservice angekommen ist. Ja, im Senden des Public Keys und abholen in der Payload Base64 diskutiert, vorhin unter Android, im Senden des Public Keys. Da haben wir das 500X509 Format. Also ist ein Standard für digitale Zertifikate. Auch Base64 codiert, check und abholen im Ciphertext genauso. Fair und Entschlüsselung bleiben Java basiert, Android läuft unter Java, dementsprechend keine Überraschung. Uja, wir können ja also schön unsere Haken dran setzen. Und nun kommen wir zu Swift. Swift ist die Sprache, die in iOS benutzt wird, zumindest in den Systemen, die wir jetzt gebaut haben. Ich kenne bisher VBR, Pascal, Lotus Notes, vornehmendlich unter Java unterwegs, bisschen Javascripten, was einem sonst so für die Füße fällt, mal die Sharp, mal dies, mal das. Also wir kennen das schon, vorgehen. Swift, iOS, Device, Schlüsse erstellen, Verschlüsselung, Entschlüsselung. Und ja, dann wird das schon gehen. Na ja, gut, wir müssen ein bisschen mit dem iOS Key Store kämpfen. Aber warum? Den gibt es nur zur Laufzeit. Also, wenn wir ein Unitest schreiben, können wir den nicht nutzen. Ein bisschen Schade so, weil den brauchen wir ja zur Laufzeit. Ich würde gerne Unitest schreiben, der genauso funktioniert, wie das in der Laufzeit auch gemacht wird. Da kann man ein bisschen tricksen und einfach in seine Hauptmethode genauso ein Test einmal einbauen und gucken, ob das da auch funktioniert, wenn man den Key Store mit benutzt. Aber ja, alles in allen, ganz schick. Das ist die Frage. War das das schon? Bisschen einfach, ne? Puh, sagt ich Mathe, bzw. kein Mathe. Ich sagte, wir brauchen voraussichtlich keinen Taschenrechner. Aber wir müssen uns vielleicht trotzdem mal angucken, wie sieht so ein Key aus? So ein Public Key, bzw. Private Key, beide bestehen aus zwei essenziellen Teilen, dem Modulus und dem Exponenten. Das ist genau so weit, das reicht, können wir so stehen lassen, die brauchen wir. Das behalten wir im Hinterkopf. Also, Vorgehen unter iOS, schauen wir uns an. Wieder Schlüssel im X509-Format, Base64 codiert. Abholung, Cypher Text, Base64. Easy, let's go. So, als die große Frage. Wir haben einen iOS-generierten Schlüssel und ein, unter Ja war, seht ihr was? Ja, wir haben ja informiertes Publikum, ne? Ganz klar, sehen wir alle. Algorithmus RSA geschenkt. Reden wir ja auch gerade drüber. Format X509, Snars N1-Dump, top. Ja klar, der Krypto-Gott, möge mich schelten. Ich seh das auch nicht. Ja, es ist zwar drin, aber alles, was ich da sehe ist, ja, ein Sidebase64 codiert, ne? Wenn da irgendwie ein paar Zeichen daneben wären und der Schlüssel ist kaputt, würde ich gar nicht mitbekommen. Na ja, leider, leider. Auf dem Ja war Service, invalid Key-Spec-Exception. Schade, so geht das leider nicht. Oder in anderen Worten, ja, wer sagt nein? Wir müssen noch ein Umweg gehen. Zwischenstopp, der Pem-Key-Container. Ich gehe davon aus einiger, haben das schon mal gesehen. Wir haben eine Theorie, ein Header und ein Futter und in der Mitte ist der Base64 encodierte Key, also in dem Fall besondere Art PKCS1. Und in der Praxis sieht das dann so aus, wir haben im Header und Futter den RSA Public Key drin stehen. Zumeist wird das Ganze als Datei abgelegt, um sich dann an verschiedenen Systemen zu authentifizieren. Und wir haben halt dieses Etikett RSA Public Key dran. Wenn wir also einfach mal in unserem System uns Dateien ansehen, dann können wir als Mensch sehen, okay, RSA Public Key, den darf ich rausgeben. Wenn da dann der Private Key dran steht, dann mache ich das lieber nicht. Also das Etikett bleibt über Header und Futter menschenlesbar. In dem Fall eben RSA Public Key. Das ist das, was iOS tut. Auf der anderen Seite haben wir Subject Public Key Info, SPKI. Es enthält ein Public Key inklusive der Metainformationen. Also das automatische Erkennen des Keyforms ist möglich und von der Intention, dass eine menschliche Interaktion vielleicht nicht so angedacht ist. Schmeißen wir unseren Key mal in einen Pempa Sarein. Also irgendeinen gibt es verschiedene Webseiten im Internet, da kann man das einfach tun. Und wenn wir RSA Public Key, den Header und Futter mit reinschreiben, dann steht dahinter ALGO RSA. Okay, Format X509, ISN1 Dump. Da ist ein Modulos drin, da ist ein Exponent drin. So schön, können wir mitarbeiten. Ja, was ist, wenn wir das RSA weglassen? Also das, was grad rot markiert ist. Java erwartet nun die Information innerhalb des Base64 codierten Public Keys. Der Kryptogott ist bühnend. So was tut man nicht. In dem Moment schlägt das ganze Fehl, weil diese Metainformationen ist nicht da. Also wir kriegen eine Pausing exception, fällt hin und irgendwas mit ISN1 Integer. Was könnte das sein? Ja, Modulos und Exponent können nicht ausgelesen werden. Wie ist der Zwischenstand? Wir haben das kreieren des Public Keys, des Keypares auf iOS und, äh, genau in iOS auf dem Device. Wir können das ganze über das Netz senden. Aber das Verschlüsseling funktioniert ja nicht. Der Key ist ja in Anführungsstrichen falsch. Wir haben also die Würde in komplatible Keys. Oh, was haben wir denn für Möglichkeiten? Wir könnten das ganze im Microservice transformieren. Wir könnten das ganze aber auch unter iOS und Zwift transformieren. Hauptsache Standard Library. Das wäre schön. Boah, gibt's nicht. Und da auch nicht. Das ist nicht schön. Also müssen wir uns überlegen, eine andere Library zu verwenden. Gibt's da irgendwas? So, unter iOS, externe Libraries. Da war nicht so viel Schönes dabei. Da wird so angeboten, hey, wir bauen dir den Private und den Public Key. Ist ja super, oder? Ich kriege es gleich beides von uns. Ich hab da Fragen. Hinterher geht der Private Key in welche Richtung und ich kriege das gar nicht mit. Ist doch nicht schön. Und letztendlich, wenn wir Kollegen haben, die das Ganze selber bauen und eine dieser Libraries, die dann verwendet werden, ja, fällt mal um, hat eine Vulnerability oder ähnliches, dann kriegen wir das ja gar nicht mit. Wir können das gar nicht richtig fixen. Dementsprechend schauen wir, ob wir das selbst bei uns im Microservice bei Java reinkriegen. Aber wenn wir das tun, ist die Nutzung kritisch. Und wenn ja, was wählen wir denn aus? Also, Kredikalitätseinschätzung. Eine externe Library schaut sich unseren Public Key an. Ja, Public Key ist erst mal dafür da, dass sie überhaupt rauskommen, aber ja, schauen wir mal. Hey, wenn der angeguckt wird, was könnte so passieren? Public Key, wir benutzen den an dieser Stelle nur für Verschlüsselung. Das bedeutet, der wird nicht zum Entschlüsseln benutzt. Wenn er irgendwie wegkommt, ist es nicht so schlimm, weil der wird ja nicht benutzt, um etwas vom Private Key des Devices kommt, wieder zu entschlüsseln. Also, soweit, soweit so gut. Dann die Erstellung des Public Keys erfolgt auf einem anderen System. Das heißt, die Library hat keine Einsicht in die Schlüsselerstellung und Private and Public Key sind sogar physisch getrennt. Und zuletzt, die Library kommt in Payloader, den Klartext nicht zu sehen. Also, erst mal gut. Und was wählen wir jetzt aus? Selber schreiben. Keine Kernekompetenz. Bitte nicht. Don't draw your own Crypto. Sehr gut. Ansonsten, wir hatten das gerade in der Exception, die wir gesehen haben. Da steht sowas von Bouncy Castle. Wir haben uns einige Libraries angesehen und diese sieht gut aus. Die kommt von der australischen Non-profit Organisation und läuft über Spenden, Support, Workshops etc. Hat die MIT-Lizenz für das, was die anbietet, gibt es schon seit mehr als 20 Jahren und das letzte Update ist jetzt auch nicht so lange her. Kann man machen. Ansonsten, wenn man auf verschiedensten Plattformen unterwegs ist, geht das ein bisschen als der One-Stop-Shop. Also, wenn du irgendwas in der Richtung benötigst, ist das auf jeden Fall eine gute Adresse. Geht das noch genauer? Ein ganz kurzer Blick. Dinge, die Bouncy Castle verspricht. Da sind ASN1-Objekte dabei, X590-Zertifikate etc. RFCs werden, wird gefolgt, also Requests for Commons, also Internet Engineering Task Force. Wir können also sagen, gemessen an unserer Kritikalitätseinschätzung, das scheint okay. Niemals ein Garant für, das ist in fünf Jahren immer noch so gut, aber für den Moment ist das in Ordnung. Ja, Zwischenstand. Wir können verschlüsseln. Da ist es schön. Empfangen des Sci-Fi-Tex auf dem Gerät, klar. Und insofern klicken wir mit Schlüsseln noch zum Transformieren des Kies. Warum ist das hier ein wenig ... Ah ja, doch, korrekt. Zum Leid. Ja, nur noch klicken und entschlüsseln. Der Private Key entschlüsselt nicht. Hm, ist ja blöd. Wir haben den ganzen Weg gegangen und was da los? Wir haben Unitests geschrieben in IOS, einmal direkt, also ohne den IOS Keystore und zur Laufzeit genauso indirekt, also mit IOS Keystore, wir schreiben den Key rein, holen den wieder raus, es funktioniert. Wir haben das Ganze mit Bouncy Cases übertragen. Den Algorithmus RSA, Format X509, Modulus Exponent übertragen auch hier noch mal ein bisschen Code. Wir haben vorher Base64, hinterher Base64 und wir nehmen aus diesem Byte Array, also das sehen wir oben links in der Ecke, das Byte Array und dann gibt es die ASN1 Sequenz. Da holen wir Modulus Exponent raus. Wir erinnern uns, es hat etwas gefehlt, nämlich die Meta-Information. Jetzt fangen wir an, das Ganze nochmal neu zusammenzubauen. Also RSA Public Key Spec packen da den Modulus rein, den Exponenten und dann hinterher mit dort in RSA zu sehen, kleben wir quasi noch dran, dass wir gerne RSA machen wollen. Am Ende wird das Ganze in ein Java Security Public Key umgewandelt. Im Java Service verschlüsselt es ohne Komplikation. Also was ist da los? RSA Decrypt Wrong Input Error minus 27. Es gibt eine Fehlerbildung, das ist ja schon mal schön. Das ist ja richtig toll, minus 27. Die Fehlermeldung ist allgemein, können damit irgendwie nicht viel anfangen. Wenn wir die App neu starten, also wir arbeiten mit der gleichen VM, der gleichen virtuellen Maschine, kriegen wir auch den gleichen Fehler. Hilft nicht so recht. Aber wenn wir die virtuelle Maschine, also das Devices, da wo die iOS App in unserem Emulator drin läuft, wenn wir die wegschmeißen, gibt es einen einmaligen Erfolg. Ja, Folgeversuche, Fehlernzeige. Ja, Sherlock. Brauchen wir mal ein bisschen Licht ins Dunkel, ne? Hier auch zu sehen, wir bauen uns einen Schlüssel zusammen. Die Details sind hier jetzt gerade nicht so wichtig. Und oben haben wir ein Tech Marker, ein sehr langer Key Store alias, um Überschneidungen zu verhindern. Also wir möchten gerne, dass wir keine Überschneidungen haben mit anderen Apps, die sich auf dem Gerät befinden und zufällig auch in unseren Key Store Keys reinschreiben wollen und irgendwie die gleiche Benahmung benutzen oder ähnliches. Okay, wir gehen davon aus, wir haben nur eine App, während wir hier testen. Also daran soll es ja wohl nicht liegen. Also Key Store Marker. Na ja, aber wir haben halt nicht daran gedacht, dass das, was wir hier an Überschreiben, an Überschneidung haben, dass da nicht überschrieben wird. Das Ganze ist ein Dictionary, da wird hinzugefügt. Das heißt, wenn wir nicht die Keys löschen, die von den letzten fünf Versuchen drin waren, dann kann es sein, dass wir beim Endschlüssel einen falschen Private Key ausholen. Und dann kriegen wir halt die minus 27. Wie so oft steht in der Dokumentation? Be sure that you don't generate multiple identical tagged Keys. Ja, super. Ja, das war eine kleine Side Note in der Dokumentation. Aber letztendlich haben wir es hinbekommen. Cool. In dem Sinn geschafft. Wir haben Android, iOS, Microsoft alles hinbekommen und wir können endlich eine Happy Parrot Rubber Duck Party veranstalten. Es bleibt. Danke für euer Interesse und bis demnächst.