 Willkommen zurück auf der remote Rhein-Ruhr-Stage, der Remote Chaos Experience in Monheim. Wir sind erreichbar im Hackent, also über IRC, im Channel RC3-R3S, unter dem Hashtag RC3R3S auf Twitter und Mastodon und auf Mastodon zusätzlich unter unserem Handel R3S at chaos.social. Der nächste Talk befasst sich mit einem der zentralen Themen dieses Jahr und besonders mit einem der zentralen Themen dieses Jahr und besonders, wie kann ich die Corona-Tracking-API als Hardware-Token bauen. Das ganze haben Lurkast und Steini gebaut und es ist sehr und was das beeindruckende daran ist, sie haben die Corona-API einmal in einen ESP32 gegossen und das ganze als Hobbyprojekt und jetzt will ich auch nicht weiter hier im Weg stehen und lange reden schwingen, sondern möchte den beiden einfach das Wort erteilen, dass die beiden dann erzählen können, was sie da genau gebaut haben. Also viel Spaß euch mit Corona-Warn-API als Hardware-Token, ESPNA und Pantra. Viel Spaß. Danke schön. Ja, danke. Ja, hallo auch von meiner Seite. Wie erwähnt genau, wir haben also die Corona-Warn-API als Hardware-Token nachgebaut, also auf einem ESP32. Damit habe ich im Juni angefangen und irgendwann später im Sommer hat mich dann Steini kontaktiert, weil die den ganzen Kram auch gerne haben wollten, um mit Cardus das zum Beispiel in Flüchtlingshemd zu bringen und so weiter. Und deswegen ist der Talk 2 geteilt. Ich mache jetzt erstmal was ein bisschen zur Technik, was ich da technisch gemacht habe und später erzählt dann Steini, wofür das ganze noch viel sinnvoller eingesetzt werden kann als nur, dass ich das auch Spaß gemacht habe. Genau. Viele Projekte zu Hardware-Token gibt es eigentlich nicht. Also viele haben nur Scanner gebaut, wo man halt sieht, wie viele Leute so drum herum rennen. Dann gibt es geschlossene Systeme, die halt mit einer anderen API arbeiten, also nicht kompatibel sind mit der Google-Apple-API. Ja, genau. Kurz zu Contact Tracing, wie das genau funktioniert, erläuter ich hier nicht, weil das sollte hoffentlich den Leuten klar sein. Es gibt ja auch eine Menge andere Talks dazu. Nur einen kurzen Überblick über die zwei Schnittstellen, sozusagen gibt es direkt die API von Apple und Google, die die zusammen entwickelt haben und in die Smartphones gebracht haben. Das regelt eigentlich hauptsächlich die Kommunikation zwischen den Geräten selber über Bluetooth Low Energy und das speichern halt von den eigenen Keys, die versendet werden und denen, die empfangen werden. Und als Erweiterung, was dann die Corona-Warn-App macht oder eben andere Tracing-Apps, die müssen dann Server bereitstellen, das Risiko berechnen machen und dort kann man halt daneben die gemeldeten Schlüssel runterladen, um die Risikoberechnung durchzuführen oder eben seine eigenen Keys hochzuladen. Genau. Und genau diese Elemente habe ich auf einem ESP32 implementiert. Ja, kurz zur Motivation daher. Einmal hatte ich eine egoistische Motivation eigentlich, weil ich ein Smartphone ohne Google Play Services habe und somit einfach die Corona-Warn-App nicht nutzen konnte und eine Lösung her musste. Ja, als Alternative für Smartphones bietet sich das an, weil ein Smartphone ist teuer, zumindest im Verhältnis 100 bis 300 Euro für ein günstiges und dann weiß man noch nicht mal, ob die App da auch läuft. Und so Hardware kostet vielleicht 10 Euro, wenn man es gut macht. Ja, außerdem hat ein Smartphone natürlich auch viel mehr Bedienelemente, wenn man jetzt an ältere Menschen oder so denkt, die werden vielleicht überfordert, das zu bedienen. Und später dazu kam, wie erwähnt, die Motivation von KADUS über Steini, dass man solche Sachen auch in Krisenregionen einsetzen könnte, eben unabhängig von der Corona-Warn-App, weil es dann eben nicht in Deutschland läuft. Ja, die technische Basis ist in ESP32. Warum? Ja, das lag hier so rum bei mir und da hat Bluetooth und Wi-Fi. Bluetooth Low Energy braucht man halt auf jeden Fall für das Austauschen der Keys und dann Wi-Fi eben, um Internet dranzukriegen, um die Keys vom RKI-Service zu holen. Genau, das Ganze basiert technisch auf dem SDK von Espressive. Espressive sind die Hersteller vom ESP32. Und das hat den Grund, dass der es zwar Arduino-Kompatibel der ESP32, aber da sind standardmäßig ein paar kryptografische Funktionen nicht aktiviert, die man braucht für die Berechnung. Das kann man wahrscheinlich auch wieder irgendwie in Arduino rein konfigurieren, aber ja, wenn man das Ganze macht, dann kann man auch direkt mit dem SDK von Espressive arbeiten. Arduino-Code basiert eh auf dem ESP-IDF, sprich, das ist der Unterbau. Es macht Arduino eigentlich überflüssig. Man hat ein Overhead, ob das performancemäßig was ausmacht. Weiß ich nicht, habe ich nicht getestet, aber ja, genau. Und das ESP-IDF ist auch modular. Dadurch kann man natürlich irgendwie verschiedene Hardware unterstützen, die man an den ESP32 anschließt und das so ein bisschen weiter tortieren. Der erste Schritt der Implementierung war nur dieser Part von Google und Apple, eben die Bluetooth und Kryptografie. Dazu muss man sagen, dass das eigentlich alles sehr simpel ist, die Grundlagen, also die komplette Dokumentation, wie technisch der Schlüsselaustausch funktioniert und berechnet wird, ist kleiner als 10 PDF-Seiten. Das war relativ schnell auch fertig. Und dann ging es eigentlich nur darum, die gesammelten Daten zu persistieren. Da habe ich dann ein bisschen Mathematik drauf geschmissen, weil so ein ESP halt nur 4 MB Speicher hat und davon sind ungefähr nur 2 MB verfügbar. Also habe ich mal durchrechnet, ob das überhaupt reicht, wenn man das in der Praxis einsetzen möchte. Zum Glück kann ich sagen, reicht es. Also die eigenen Schlüssel, die man speichern muss, sind pro Schlüssel 21 bytes und da hat man 14 Stück für. Das ist halt zum Glück nichts. Und dann geht es eben um die Beacons, also die Geräte, die man in der Nähe eingesammelt hat. Das ändert sich ja so im Schnitt alle 10 Minuten. Also muss man so in 10 Minuten in Tabellen rechnen. Und da bin ich bei dem freien Speicher ungefähr bei 70.000 Beacons, bei 32 bytes pro Beacons. Und wenn man das runterwechnet, sind das 34 Geräte in 10 Minuten, die ich treffen kann im Durchschnitt bei 24 Stunden und 14 Tagen. Was natürlich dann in der Praxis auch deutlich mehr ist, weil man eben Schlafzeiten hat, wo man keinen trifft und so weiter und mal größer unterwegs ist. Sprich, ja, ich denke, der Speicher reicht zum Glück aus, dass das wirklich praxistauglich ist. Ja, die Risikoberechnung habe ich dann nach der ersten Version von Apple gemacht. Das hat natürlich damit zu tun, dass als ich angefangen habe, gab es auch noch gar keine anderen Versionen von der Risikoberechnung. Mittlerweile hat ja die Corona-Warn-App eine neue Berechnung veröffentlicht und auch ziemlich gut dokumentiert. Insofern denke ich mal, dass wir das bald einbinden werden und auch so machen werden. Ja, der nächste Schritt war dann das eigentlich Schwierige, nämlich genau das, was die Corona-Warn-App macht, umzusetzen. Nämlich die Kies vom Server zu holen und eben eine Schüssel hochzuladen. Und da ist das Problem, dass der ASP32 leider viel zu wenig Ram hat. Das sind einmal SIP-Falls, die entpackt werden müssen. Und dann sind das binary-Daten im Protocol-Buffer-Format. Dafür gibt es zwar auch eine tolle Library in C, aber bei den Größen ist es einfach nicht möglich, auf dem Gerät so eine große SIP-Datei zu entpacken. Und da reden wir immer noch nur von ein paar Hundert Kilo bald. Ja, also ist die Lösung. Wir machen ein Proxy dazwischen. Der holt sich einfach die, stündlich die Daten vom Corona-Warn-App-Server und speichert dener Datenbank. Und der ASP32 fragt die Kies einfach mit einer Pagination ab als binaries. Und ja, da sind wir bei 28 Breitpro Kies. Als default habe ich 500 Kies pro Request. Und dann ist man natürlich, je nachdem wie viele Kies es sind, soweit 30 bis 60 Request am Tag. Das geht eigentlich auch wunderbar. Und da über den Proxy ist gerade auch der Ablaut der eigenen Kies geregelt, wo man halt eine Tonne mit schickt. Dazu muss man kurz sagen, dass der Proxy aktuell die Tonne noch nicht weiter leitet an die Corona-Warn-App. Aber das sollte so kein Problem sein. Vielleicht können auch ein paar Leute hier beim Kongress, der viele Talks über die Corona-Warn-App da auch noch kurz unterstützen. Ja, aber genau. Und damit sind eigentlich alle Funktionen der Corona-Warn-App abgedeckt. Ich kann andere Devices sehen. Ich habe selber sende meine Schlüsse raus und speicher die und hole mir bis zuständig die aktuellen Kies, vergleich die und mache eine Risikoberechnung. Ja, hier habe ich einmal dann die Hardware aufgezeigt. Also links ist mal ein schönes selbst gebasteltes Ding, womit ich angefangen habe. Und rechts dann Hardware, die man kaufen kann. Das ist ein M5 Stick von M5 Stack. Das sind so Maker Devices, die man relativ günstig kaufen kann. Und die haben dann alles und mehr als das, was ich links im Bild habe. Was braucht man unbedingt? Also eine Real-Time-Clock ist wichtig, weil die Zeit spielt auf jeden Fall eine wichtige Rolle, weil man muss ja speichern, wann man jemanden getroffen hat und von wann seine eigenen Kies ist. Also Zeit und Datum muss stimmen. Sonst funktioniert natürlich der ganze Abgleich nicht. Und ja, an dem Display, dass man eben ein kleines Interface hat, um den Status anzuzeigen, dass man infiziert ist, ein paar Infos und um die Tanz einzugeben, braucht man dann noch ein Input genau. Da habe ich so ein kleines Interface gebastelt. Was noch vielleicht erwähnenswert ist, weil viele immer bei der Corona One App auch die Gamification anmerken, dass man quasi da irgendwie Merkfalt mit der App verbringen sollte, um da Sensibilisierung zu machen. Also wir haben natürlich den gegenteiligen Ansatz, dass man quasi nur im Notfall aufs Display gucken sollte. Also ist das vielleicht piept oder anfängt zu leuchten, wenn man wandt, weil wenn es aus ist, spart man halt Akku. Genau, das ist wichtig. Ja, was haben wir für Baustellen aktuell? Also man braucht halt Wi-Fi, das klingt im ersten Moment trivial, aber ja, wir reden halt eigentlich von Einsatz bei Leuten, die eben kein Smartphone haben. Und dieses Einrichten von Wi-Fi auf dem Stick ist jetzt auch nicht benutzerfreundlich, sag ich mal. Es muss halt irgendwie verknüpft werden. Ja, was sind Lösungen dafür? Auf jeden Fall Freifunk wäre super. Oder man hat feste Hotspots irgendwie. Aber das ist auf jeden Fall eine Baustelle. Und dann die Akkulaufzeit. Also dieses Dicks haben aktuell leider einen sehr kleinen Akku drin. Und da man immer Bluetooth anhaben muss, sieht das, das ist der ESP32 leider sehr ineffizient im Vergleich zu anderen Bluetooth Low Energy Chips. Deswegen haben wir eine Laufzeit von aktuell ca. 2 Stunden. Also es ist wirklich nicht so praxistauglich. Zum Glück kann man eine Powerbank einfach dran machen. Also das ist die simple Lösung. Hält das auf jeden Fall deutlich länger. Außerdem arbeitet Espressive auch einer Lösung, weil das ist wohl eher ein Softwareproblem, wie der Bluetooth Low Energy Chip angesteuert wird. Und ja, mit Glück kommt halt irgendwann einfach ein Update und wir haben vergleichbaren Energie verbraucht für Bluetooth, wie andere Chips haben. Also da ist der ESP32 leider eine Ausnahme. Dann wollte ich natürlich noch kurz zum Datenschutz eingehen, weil es ja auch immer ein Thema ist, welche Daten darauf gespeichert werden. Also die persönlichen Daten sind eigentlich, die werden das nur die Wi-Fi Credentials, wenn man die drauf hat, also wenn man jetzt in seinem eigenes WLAN oder so sich verbindet. Das ist das Einzige, was so persönlich ist. Ansonsten sind da halt nur die Schlüsse drauf und die gesammelten. Das heißt bei Verlust, ja, wäre es eigentlich nicht kritisch. Außer eben die Wi-Fi Credentials werden irgendwie sehr sensibel, aber kann man hoffentlich verschmerzen. Also ist eigentlich in der Theorie sogar nur der Diebstahl ein Problem, wenn einer halt bewusst sagt, ich möchte einen Trocken haben, weil ja, die Daten liegen natürlich einfach unverschlüsselt im Speicher. Also wer Zugriff auf die Hardware hat, kann eben die Schlüssel auslesen. Ich habe mich nicht intensiv damit beschäftigt, wie das bei Google oder Apple funktioniert, aber ich vermute mal, dass man da nicht so simpel darauf zugreifen kann, nur wenn man jetzt ein Handy findet, genau. Aber generell fallen halt bei dem Gerät eigentlich überhaupt keine persönlichen Daten an, außer das Wi-Fi. Also das ist ja auch der Vorteil von dem ganzen System von der Exposure Notification API, dass sie sehr datenschutzfreundlich ist. Ja, genau. Und jetzt darf Steini übernehmen, weil wir haben dieses Trocken halt auch nicht nur für die Corona-Warn-App, sozusagen entwickelt in Deutschland, sondern das soll auch weitergehen. Und das ist natürlich eine Challenge, die ein paar mehr Probleme mit sich bringt und ein paar mehr Aufgaben, weil man eben kein Server von Telecom und SAP dahinter hat, sondern so ein paar Dinge dann auch noch selber lösen muss. Deswegen übergebe ich jetzt an Steini. Dankeschön. Ja, großartig. Vielen Dank für die ausführliche Einführung in diese Technik. Erstmal muss ich auch noch ein paar Dankesworte loswerden, dass ihr mitkriegen müssen, was kurz vor den Talk hier los war, weil mein Rechner dann Mumble und dann das Videoconferencing. Also alles funktionierte nicht. Und die haben hier gerade das großartige Team von dieser Bühne. Hier hat gerade in Windeseile Lösungen geschaffen, die dann auch noch einfach so funktioniert. Ich bin total begeistert. Dann ist es natürlich auch nicht ganz richtig, dass Lukas und ich das entwickelt haben. Ich habe erst mal überhaupt gar nichts gemacht, außer was haben wollen. Und mit dem Team war noch der Micha, Sam, Hund, Fox. Also es war schon ein paar mehr, aber man muss neidlos anerkennen, Lukas hat die Hauptarbeit der Implementierung dieser ganzen Protokolle gemacht und hatte auch schon ganz viel, als wir kamen und sagten, so was wollen wir eigentlich auch aus mehreren Gründen. Und dann dachten wir müssen ja nicht das Rad neuer finden. Und Lukas war gleich total begeistert und voll dabei, sodass wir einfach ganz viel Arbeit nicht hatten. Umso schneller sind wir jetzt, wo wir sind. Zwei wesentliche Aspekte treiben uns da eigentlich an. Der eine ist, dass es natürlich doof ist, dass man ein aktuelles Smartphone haben muss, um mitspielen zu dürfen. Das ist weder sehr vertrauenserweckend, weil die Kritik in der Community ist ja auch berechtigt zu sagen. Super cool, jetzt haben wir eine Corona-Warn-App und die ist open source und die ist auch irgendwie datensparsam und schützt die Privatsphäre und läuft die auf dem Smartphone, die eine wandelnde Wanze mit Personal-Personenbezug ist und wo auf Privatsphäre letztlich im weitesten Sinne geschissen wird auf Deutsch gesagt. Das ist nicht so wahnsinnig cool. Außerdem geht es nur, wenn man viel Geld dafür bezahlt hat und aktuelle Hardware hat. Das ist auch nicht besonders nachhaltig und ökologisch und so weiter. Das war für sich genommen schon ein Grund zu sagen, der zweite Grund war auch ein bisschen zu sagen, wir wollen natürlich auch wissen, wie open source ist es denn. Ich finde ja, open source ist nur dann open source, wenn man daraus auch was selber bauen kann, was dann mitspielen kann. Das ist ganz offensichtlich der Fall, was ich großartig finde. Und der dritte und vielleicht Hauptantriebspunkt war, dass wir bei Cardus, also vielleicht muss man kurz zu Cardus was erklären. Cardus ist ein NGO, der im weitesten Sinne medizinische Hilfe in Gebiete bringt, wo sonst eigentlich niemand mehr hin will. Also Syrien, Nordsyrien, Nordost, was war es? Irak, Nord Irak, Nordostsyrien, so rum. In Flüchtlingslager, jetzt auch in Griechenland und so weiter. Also immer da, wo es richtig ärgerlich wird und richtig problematisch wird, wo es politisch nicht einwandfrei ist, die Lage nicht einwandfrei geklärt ist, irgendwo zwischen den Fronten und so weiter. Und da sind natürlich die Zustände, die hygienischen und medizinischen Zustände am katastrophalsten. Und eigentlich wollen sich internationale Hilfsorganisationen damit auch gar nicht so sehr gerne mehr beschäftigen, weil man da schnell politisch auch zwischen Fronten gerät, indem man eigentlich nicht sein will. Trotzdem ist es natürlich immens wichtig, auch da Hilfe zu leisten und wer hätte es gedacht, das ist jetzt mit Covid-19 nicht einfacher geworden, aus ganz vielen Gründen. Es ist natürlich auch das Reisen schwieriger geworden. Es ist aber natürlich auch das Risiko in diesen Flüchtlingscamps auf den große Zahlen von Menschen auf kleinstem Raum unter hygienisch katastrophalen Bedingungen zusammenleben, gerade nochmal extra doof. Und jetzt auch nicht nur wegen Covid-19, sondern auch wegen allen möglichen anderen Infektionskrankheiten, die dann kursieren. Und da war dann die Idee, naja, das ist natürlich echt schwer, den jetzt alle ein Smartphone in die Hand zu drücken. Manche haben das tatsächlich sogar, aber auch die Infrastruktur ist natürlich nicht gegeben. GSM-Zellen und so weiter ist alles ein bisschen schwierig. Und die Idee lag nahe. Jetzt hier tatsächlich für kleines Geld, das ist ja nahe nichts mit einem Gehäuse, kleine Batterie. Da kann man locker unter 10 Euro bleiben, wenn man das ordentlich optimiert. Da kann man dann schon mal ein paar Tausend Camp-BewohnerInnen ausstatten mit solchen Geräten. Und eine Baustelle, an der Carlos auch arbeitet, ist eben Covid-19-Testing. Also mobile Labore vor Ort zu haben, jetzt nicht nur für Covid-19, sondern eben auch medizinische weitere Ausrüstung, um dann aber eben auch sozusagen als kleine Autarkentität in so einem Camp auch das Infektionstracking zu ermöglichen. Und eben möglicherweise auch nicht nur Covid-19, sondern auch in anderen Kontext. Und da bot sich das jetzt halt wahnsinnig gut an zu sagen, ja, das löst ja fast alle Aufgaben, die wir haben. Man könnte die für so eine Anwendung natürlich auch vorkonfiguriert haben, den Wi-Fi-Access-Point an neuralgische Punkte stellen, wo auf jeden Fall die Leute am Tag einmal vorbeikommen. Deswegen auch ein bisschen die Entscheidung für den lokalen Proxy, der natürlich auch technisch Sinn ergab, auch insofern Sinn ergibt, als dass das jetzt auch eine komplette Stand-alone-Lösung sein kann. Der Proxy muss jetzt nicht an irgendeine offizielle Datenbank angeschlossen sein, sondern er kann auch lokal die Informationen weiterverarbeiten. Und woran wir jetzt gerade noch denken, das ist ja zur Status, wäre ein Träumchen. Und da müssen wir aber genau rausfinden, wie das sozusagen privatsphäerisch schützend vernünftig geht. Das größte Problem in diesen Camps ist, dass wenn sich jemand hat testen lassen und dann rauskommt, dass der oder die Person tatsächlich positiv getestet wurde, dann muss man diesen Menschen erst mal wiederfinden und das auch mitteilen können. Das ist überhaupt nicht selbstverständlich. Und da war jetzt sozusagen die Idee, wenn Labor- und Behandlung der und grobenehmende Arztärztin quasi personenidentisch sind, dass wir dann eine privatsphären schützende Variante hinkriegen, mit denen wir die Person, die getestet wurde, auch über das Gerät benachrichtigen können, auf einem zweiten Wege sozusagen, dass das so ist und dann sozusagen möglicherweise, aber wie gesagt, alles noch nicht völlig durchdacht, stellvertretend alle anderen benachrichtigen, die dann eben auch in Kontakt standen. Nach wie vor dann natürlich wieder vollständig anonym. So, weil letztlich das Labor, das die Probe genommen hat, weiß ja von wem sie die Probe genommen hat, das ist ja nur an der Stelle nicht anonym. Und an der Stelle wäre die dann auch vor Ort nicht. Aber hier, also das größte Problem beim Corona-Testing auch in Deutschland ist nach wie vor, dass die Labore überhaupt nicht vorbereitet sind und überhaupt nicht so durchdigitalisiert sind, dass diese Meldungen dann einfach auch tatsächlich vollautomatisch weitergeleitet werden, da werden Faxe geschickt, teilweise. Das ist beeindruckend rückständig, sagen wir mal, weil es in der Stelle auch nicht zu lösen, aber so ist es halt und das ist Status quo und ja, wir sind total guter Dinge. Das Projekt dann auch ein bisschen, wenn es jetzt richtig fertig und getestet und so ist, ein bisschen in die Breite zu kriegen. Und dann eben einerseits hier, also in Deutschland, am Geschehen teilnehmen zu lassen für die Menschen, die das können und Bock drauf haben, die darauf aufsetzen wollen. Es gibt ein paar Ansätze auch mit dann so Smartwatches, mit ESP32 basiert oder anderen Lösungen. Das ist ja dann ein Sourcecode, der frei weiter verwendet werden kann und soll. Und eben auch Dinge zu bauen, die dann eben in solchen Heiklin-Szenarien wie großen Camps mit schwieriger Gesundheitslage, sag ich mal, eingesetzt zu werden. Ja, ich würde sagen, soweit der Rundumschlag und wenn ich das richtig verstanden habe, wollen wir Raum, die für Fragen und Ideen, Anregungen und so. Genau. Ja, das, was Steini gerade kurz angesprochen hat, kann ich natürlich auch noch erwähnen. Das habe ich vergessen. Der Code ist natürlich open source und auf GitHub. Jo, vielen Dank für euren Talk. Ja, es haben sich auch einige Fragen angesammelt. Also gehe ich auch mal davon aus, dass entsprechend viel Resonanz da war. Da hätten wir zum einen Leute zugeschaut, ja. Ja, da wird zum einen der offizielle, also Anführungszeichen offizielle, Corona-Warn-Buzzer soll trotz 2 Millionen Förderung ungefähr 50 Euro pro Stück kosten. Seht ihr größeres Potenzial für diese Open Source Alternative? Ach, Potenzial ist ja immer in beliebigen Mengen vorhanden, sag ich mal. Aber ja, selbstverständlich, also Open Source, ich meine, nicht zuletzt haben wir beim CTC und natürlich auch an anderen Stellen vehement gefordert, dass diese kritische Open Source sein muss, damit es ja einerseits eine Überprüfbarkeit gibt, wie es denn funktioniert und ob die Privatsphäre wirklich gewahrt bleibt. Aber natürlich auch, um ja, eine möglichst gute Verbreitung zu erreichen auf vielen Geräten, in vielen Bereichen, in vielen verschiedenen Anwendungen. Und ich würde das auch gar nicht gegenüberstellen, nicht sagen das eine oder das andere. Ich kann mir vorstellen, dass ein Gerät, das mit ein bisschen entsprechendem Entwicklungsaufwand, der über das hinausgeht, was wir jetzt so in der Freizeit leisten können, dann auch das Geldwert ist. Ich kann mir auch vorstellen, dass es genauso okay ist zu sagen, man baut sich so was für 10 Euro selber oder es findet sich irgendeine Entität, die dann sagt, wir replizieren das und machen da auch Stückzahlen draus und dann geht es auch für deutlich billiger. Was ich komplett grundfalsch finde, und da kenne ich jetzt aber das Produkt da nicht, ist, wenn jemand anfängt, damit Kohle zu machen zu wollen, also Profitinteresse hat, dann würde ich sagen, ja, troll dich, das finde ich doof. Aber was zum Fehlern selbst kostet, natürlich soll die Leute bezahlt werden am Ende, die es machen. Da ging es nichts einzubenden. Aber ich finde, Selbstkostenpreis muss drin sein, da soll die Arbeit enthalten sein, aber Profitinteresse damit zu schüren, das fände ich grundfalsch und verwerflich. Okay, dann wäre die nächste Frage. Dient der Proxy dann für mehrere ESPs? Ja, klar. Also das ist halt ein Server aktuell. Ja, es ist natürlich jetzt nur von uns aufgesetzt. Also ich vermute mal, dass er nicht skaliert. In der Theorie kann man aber halt auch, also der Servercode ist natürlich auch Open Source, kann man sich so ein Ding auch eben schnell aufsetzen. Aber ja, also einfach nur, dass das Gerät nicht mit dem Server von der Corona Warn erbredet, sondern sozusagen mit dem Proxy. Also das funktioniert eigentlich analog. Dass es eine URL gibt, wo die Kies abgefragt werden. Genau, da haben wir jetzt nicht so den Fokus drauf gelegt, aber natürlich kann man denen so bauen, dass da auch 100.000 Geräte gegen Konekten, das ist jetzt eine Frage der Skalierbarkeit. Da gibt es bestimmt Menschen, die das viel, viel besser können als wir, aber technisch sind denen ja keine Grenzen gesetzt. Wichtig ist eben nur, dass dieses doch sehr komplexe hin und her mit großem Speicherbedarf hier optimiert wird, weil das geht auch so klein, die Preise werden gereden nicht. Genau, also es wäre auch spannend, ob nicht so jemand wie Telekom oder SAP, wenn man das größere Auftritt nicht einfach auch die Schnittstelle bieten, weil das ist ein simples Binary Format. Also großartig, genau, das wäre toll. Okay, dann hätte ich noch die Frage, habt ihr irgendwelche Mechanismen eingebaut, um die Datenintegrität der gespeicherten Daten sicherzustellen? Also aktuell auf jeden Fall nicht. Wir haben erstmal nur simpel auf SSL gesetzt. Das ist eigentlich das Einzige, also der SP-Krichten, ein Zertifikat mitgeliefert, um die Verbindung zu prüfen, also das aktuell alles. Ja, darüber gegrübelt und Ideen gehabt haben wir viele, aber ja, das sind einfach Sachen, die mit, es ist wie gesagt immer noch ein Nebenprojekt gewesen. Also niemand wurde dafür bezahlt. Und dementsprechend, ja, bin ich erst mal darauf, dass es so weit funktioniert, wie es jetzt funktioniert und wir gerne keine Anbindung haben. Optimierung gibt es auf jeden Fall noch in vielen Richtungen. Also man kann zum Beispiel auch irgendwie den Speicher auch verschlüsseln, das ist möglich auf dem SP, aber das sind alles Dinge. Ja, da war jetzt keine Zeit für sich da näher mit zu beschäftigen. Es ist ja auch ganz wichtig hier nochmal zu erkennen, dass gerade in solchen Open Source Projekten die Chance besteht, für alle dann mitzuarbeiten. Und ja, die Community kann, darf, soll Hand anlegen und das verbessern und muss jetzt aber die ganze Fitzelarbeit nicht nochmal machen, sondern jetzt kann es losgehen und funktionieren im Code. Also give us code ist also die Grundidee in den Bereich zu sagen, jetzt haben wir was, das funktioniert, das ist frei verwendbar. Go crazy, wir brauchen ein, zwei, viele solche Lösungen. Ja, genau, da kann ich auch nochmal ganz kurz anmerken, dass das von mir persönlich mein erstes Projekt im embedded Bereich in zähl ist. Also ich bin auf keinen Fall ein Experte, ich habe immer nur kleine Bastelprojekte gemacht mit Arduino und so weiter, jetzt da. Also ich freue mich wirklich über jegliche Expertise, die sich den Code anschauen und verbessern, weil ja, es ist definitiv keine professionelle Arbeit. Und das ist absolut großartig, vielen Dank. Dann hätten wir noch die Frage, sind die Bluetooth-Device-IDs bei euch randomisiert? Es gibt ja einmal die Corona-Warn, die im Corona-Warn-Protokoll übertragende ID, aber auch noch eine Art Mac-Adresse, die auch randomisiert werden muss. Ja, ist randomisiert. Da möchte ich nur hinzufügen, das steht in den Bluetooth-Spezifikationen drin von Apple und Google und dementsprechend, also das ist alles zu 100 Prozent zu umgesetzt. Also die Mac-Adresse wird im Bereich zwischen 10 Minuten und 20 Minuten randomisiert und dann wird ein neues Code gesendet. Also, ja. Dann noch eine letzte Frage. Das Auswerten der Daten während der De-Kompression war nicht möglich? Ich weiß nicht, ob die De-Kompression von der SIP-Fall gemeint ist. Also bei mir hat es einfach nur meine Sehkenntnisse übertroffen, jetzt einen eigenen Entpacker zu schreiben und ich habe halt versucht, Libraries einzubinden, wie ZLIP und so weiter, oder ich glaube, Nano-SIP gibt es noch. Ja, und eigentlich kann man direkt ein Speicher overflowen, wenn ich auch irgendwie diese SIP-Dateien damit angefasst habe. APIs gefunden, um irgendwie nur teilweise Daten daraus zu lesen, habe ich leider nicht. Aber wenn es hier einen Bitschupster gibt, der das geschoben kriegt. Ja, genau. Also das Problem ist halt den Request. Also theoretisch kann man natürlich dann wieder die Request auch in den Flash-Speicher lesen und nicht in RAM, da hat man aber das Ding, dass der natürlich eigentlich gebraucht wird, um die Kies zu speichern. Also da hat man auch ein Interessenskonflikt und ansonsten, ja, man stellt ein Web-Request und müsste dann da schon partiell die Daten daraus lesen. Es übersteigt meine Expertise, ob das überhaupt möglich ist. Okay, das war's. Ah, es gab einen Nachtrag. Ja, genau, das ZIP-Fall war gemeint. Ja, also dann danke für einen spannenden Talk. Es ist auch wieder schön, wie ihr gezeigt habt, dass auch wenn man am Anfang noch nicht viel über die Umgebung, mit der man arbeitet, weiß, dass es trotzdem möglich ist, da auf ein doch sehr, doch sehr vollständiges Endergebnis zu kommen. Und das ist immer wieder schön zu sehen. Dann danke euch für euren Talk. Danke, dass ihr euch die Zeit genommen habt, hier virtuell herzukommen. Und ich wünsche euch noch viel Spaß beim RC3. Ja, danke, danke dafür, dass ihr so eine tolle virtuelle Bühne bietet und den Raum schafft. Und ja, dann bis gleich irgendwo auf der Welt, in der 2D oder 3D. Ja, genau. Wir freuen uns auch noch natürlich über Nachfragen später. Kontaktiert uns einfach. Ich habe auch RC3-Assemblies hier auf der Folie verlinkt. Genau, ansonsten nehmt irgendwie Kontakt mit uns auf. Wie gesagt, ich freue mich über Expertise. Wir freuen uns über Feedback-Infos. Und ja, spread the word. Genau. Und Kados findet ihr auch im OYO auf der Worldmap eher unter Software lustigerweise. Nein. Okay, cool. Danke. Alles klar. Danke schön. Tschüss. Tschüss.