 Obwohl die Titelbeschreibung in Englisch war und auch die Beschreibung in der Beschreibung auf Englisch war, würde ich den Talk of Deutsch schalten. Er ist relativ kurz gehalten und ich würde am Ende lieber nochmal ein bisschen von euch Fragen beantworten und ein paar Sachen klären. Leider hatte ich nicht genug Zeit, mich vorzubereiten, weil auf der Arbeit einiges schief gelaufen ist. Aber ich hoffe, es ist trotzdem interessant für euch. Ich würde einmal ganz gerne von euch wissen, wie viele von euch machen denn irgendetwas mit IoT? Und wem sagt denn auch so etwas wie Sexlobhan etwas? Cool! Cool, also ungefähr so sieben Leute von, ich glaube, 30, können mit Sexlobhan etwas anfangen, was relativ viel ist, aus meinem Erfahrungsschatz heraus. Und es kommen immer noch mehr. Worum geht es eigentlich? Es soll um ein bisschen IoT gehen, und zwar jenseits von Wi-Fi, jenseits von Raspberry Pies, dass man halt nicht unbedingt einen ganzen Linux-Service schrinken muss auf ein kleines Device und den bittlich anbindet, am besten via Wi-Fi, weil dort gibt es einige Restriktionen, die man eigentlich gerne umgehen möchte. Man kann nicht überall volle Linux-Systeme haben, insbesondere wenn man über dieses klassische IoT in den Bereich Home Automation redet, sind da einige Anforderungen, die nicht so einfach zu erfüllen sind. Ich würde mich freuen, wenn einige Leute danach ein bisschen damit rumspielen würden. Und das in den Hackerspace ist ein bisschen dazu dann geschieht in den nächsten Jahren, weil es doch eigentlich eine ganz schöne Variante ist, ohne proprietäre Stacks, ohne Patente, ohne Probleme eigentlich, Dinge zu tun im Nahbereich. Das heißt, was ist eigentlich die Motivation von uns? Wir wollen natürlich irgendwie alles mit allem verbinden. Es soll irgendwie funktionieren und wollen wir wirklich eigentlich alles verbinden? Wir haben eigentlich ganz gute Erfahrungen gemacht mit dem Internet. Und irgendwie funktioniert alles miteinander, indem wir Standards bereitstellen. Ein paar Sachen haben nicht so ganz gut geklappt. Aber das Grundkonzept ist, wenn wir irgendwie Pakete schicken mit IP, sollte das eigentlich ganz gut klappen. Wir haben uns mehr oder minder auf HTTP geeinigt, also ein restvolles Protokoll, mit dem man ganz schön einige Sachen machen kann. Die Frage ist, wollen wir das eigentlich auch im Bereich Internet of Things machen? Wollen wir da irgendwie sowas machen wie im Home Automation Bereich, jede Glühbirne, jeden Lichtschalter? Und andere Dinge machen, warum bringe ich das Beispiel mit Home Automation, weil es eigentlich mal sehr nah ist für Leute zu sehen. Wir haben viele andere Anwendungsfälle, wo es ähnliche Anforderungen gibt, die ähnlich problematisch sind. Und wenn man von Home Automation anfängt zu reden, würde ich halt immer die klassischen Beispiele bringen, die Glühbirne. Denn dort, das ist eigentlich das naheliegendes, weil man möchte etwas einausschalten. Jeder hat mehrere zu Hause, man hat Schalter, man hat ein Temperatursensor, den will man wieder weiter verwenden. Da möchte man typischerweise nur etwas rauslesen und natürlich die AC, die Heating, die möchte man irgendwie regulieren, steuern, irgendwie vernetzen mit anderen Dingen, denn dort könnten einige Sachen abhängig sein. Generell, wenn ihr Fragen habt, stellt sie ruhig zwischendrin. Und ich würde dann danach ganz gerne noch mit euch darüber diskutieren, wer dann Lust hat. Das Ganze soll auch möglichst günstig sein. Das heißt, wir reden hier von Constraint Devices. Die meisten von diesen Constraint Devices liegen im Bereich von wenigen Kilobyte von RAM. 16 Kilobyte, 32 Kilobyte RAM sind normal. Das heißt, wir haben spezielle eingebettete Betriebssysteme. Wir können dort nicht einfach mal ein SSR-Sover hochfahren oder ähnliche Dinge. Wir müssen dort also wirklich aufpassen, was können wir dort machen. Das sind wenige Mega-Herz, was aber eigentlich auch nicht so das Problem ist, weil wir wollen ja auch nur ganz wenige Dinge tun. Lichtschalter, wie gesagt, eine Glühbirne sollte andere oder aus sein. Das ist ja auch nur ein Bedan-Information. Flash, typischerweise in diesen günstigen Devices, reden wir von 6428 Kilobyte Flash. Inzwischen auch ein Megabyte teilweise. Das heißt, dort muss es möglichst effizient alles untergebracht werden und entsprechende Libraries müssen angepasst werden. Battery-Power hat klingt jetzt erstmal komisch, aber in dem Augenblick, wenn man halt ein Lichtschalter hat, die möchte man nicht noch extra eine Stromversorgung angedeihen lassen. Das heißt, in dem Augenblick heißt es, wir müssen Strom sparen an jeder möglichen Stelle. Das heißt, möglichst wenig senden, möglichst wenig komplizierte Verarbeitung durchführen und den Stichwort Duty Cycle möglichst viel im Standby sein. Das heißt, wenn ich im Standby bin, habe ich typischerweise Probleme, dass ich nicht erreichbar bin, ich muss irgendwann wieder aufwachen, ich muss mich darum kümmern, wie schnell kann ich wieder aus einem Standby aufwachen und dann diese entsprechenden Pakete verarbeiten. An diesen Stellen haben wir einfach andere Voraussetzungen, als für typischerweise bei den normalen Internetgeräten der Fall ist, die wir alle kennen und nutzen. Ich hoffe, es ist klar, warum ich nicht unbedingt über IPv4 anfange, als Recap das zu haben. Wir wollen eigentlich gar kein neues IPv4 mehr ausrollen. Ich glaube, es ist jedem klar, warum das Problem ist. Wir haben in diesem Augenblick relativ große MTUs, Maximum Transmission Units, müssen mindestens 128 bytes sein. Das heißt, das muss man laut Standard erst mal erfüllen und man muss 128-Bit-Adressen verarbeiten können. Klingt jetzt erst mal nach, okay, wo ist das Problem? Der ganze Standard wurde ratifiziert, ohne dass man kleinere Geräte im Blick hatte und man hatte eigentlich nicht damit gerechnet, dass IPv6 vernünftig auf kleinen Geräten läuft. Stichwort 16 Kilobyte RAM, dort einen vollständigen IPv6-Stack einzuführen, ist relativ schwierig. Daran wurde relativ viel Arbeit reingesteckt in den letzten Jahrzehnten und 2007 ist mit 6 Lopern eine Adaptions-Layer eingeführt worden für eine bestimmte Sache. Aber fangen wir erstmal an, warum das eigentlich wichtig ist im Bereich IoT. Wenn wir uns einfach mal klassisch anfangen, wir haben einen Lichtschalter. Wir haben meistens genau ein Bit an Informationen, das wir übertragen möchten. Das Licht soll angehen oder ausgehen. Wir wollen es eigentlich nur tockeln. Das heißt, wenn wir jetzt kurz überlegen, 128-Bit-Adressen, eine relativ große MTU, noch mehr overhead, wir reden hier immer davon, dass wir nur ein Bit an Informationen übertragen wollen meistens. Inzwischen noch ein bisschen dimm, okay. Das Wichtigste ist aber auch, wir wollen das sofort tun. Es gibt von Siemens ein Standard, wenn ich mich rechte, der sagt, von 250 Millisekunden eine Lampe reagiert auf den Lichtschalter, wird der Nutzer nochmal den Lichtschalter betätigen. Mit allen Konsequenzen, die daraus entstehen. Das heißt, wir müssen schnell reagieren. Wir werden auch das Feedback direkt an eine Lampe normalerweise sehen. Das heißt, es ist eigentlich gar nicht so wichtig, dass da bestimmte Dinge passieren. Und wir wollen es auch gar nicht sehen. Dagegen haben wir Temperatur- und Luftfeuchtigkeitssensoren klassischerweise. Die wachen auf, lesen irgendwann mal ihren Wert, sagen okay, es sind 22,3 Grad in einem Zimmer, senden den raus, schreiben den raus und sind wieder für fünf Minuten weg. Das stört keinen, die werden weggeschrieben, wenn der mal jede zweite Nachricht verloren geht. Wäre uns glaube ich auch nicht so schlimm, wäre halt ein bisschen schade drum, aber das ist nichts, was irgendwie zeitkritisch ist. Das heißt, dort haben wir komplett andere Anforderungen an die beiden Geräte. Wir haben so ein Fall von Window Locks, also Schließsysteme, wo wir zum einen ganz gerne wissen wollen, was für ein Status hat eigentlich diese Schließsysteme gerade. Und wir wollen auch verlässlich zum Beispiel wissen, hat es jetzt diesen Status gesetzt, ist das passiert? Das heißt, wenn ich jetzt sage, hey Fenster, schließe dich bitte, möchte ich gerne wissen, ist der Befehl durchgekommen, wurde ausgeführt, ich möchte gerne Feedback haben und dort wieder diese Anforderungen, dass ich das verlässlich haben will. Und auch hier wieder, es sind eigentlich wenige Beids an Informationen und Sachen, die wir machen möchten. Für die Heimvernetzung oder generell für Wireless, also Low Power Wireless LAN, Wireless Personal Access Networks, ist der Standard IEEE 8254 mal entwickelt worden. Der ist 2003 ratifiziert worden, 2006 ist eine Version rausgekommen. Die meisten werden ihn kennen, weil SIGB darauf ausbaut. Der Schöne ist, das ist halt ein lokaler Funkstandard, der wurde darauf entwickelt, möglichst wenig Energie zu verbrauchen. Ja, Funk, klassischerweise im 2,4 Gigahertz Band, mit 5 Megahertz breiten Kanälen, relativ langsam ist für Signalling gedacht. Das heißt, wir senden wenige Informationen. Später kamen noch die Bender 868 Megahertz, 915 Megahertz dazu, als auch 433 Megahertz, um mehr Reichweite zu ermöglichen bei immer noch sehr geringer Datenrate. Das heißt, damit kann man solche Lichtschalteranwendung ganz gut realisieren. Ja, das Problem an der ganzen Geschichte ist, er wurde spezifiziert für 127 Byte Frames. Wenn wir jetzt noch mal zurückdenken, IPv6 wollte 1280 Byte Minimum als Transmission Unit. Das muss gewährleistet sein. Das heißt, in diesem Augenblick können wir schon kein natives IPv6 mehr in ein Frame reinpacken. Wir würden über mehrere Pakete reden, die geschickt werden müssten. Wenn er an Empfänger mehrere Pakete entfängt, müsste er die reassemblen. Wenn er irgendeine Störung reinkommt, gibt es wieder Probleme. Das ist nicht so günstig. Eine andere Sache ist, zur Adressierung wer eine 64-Bit-Große ID verwendet, ähnlich wie die Identifier bei IPv6, wenn man das Prefix wegschneidet, und genau dort kann man dann auch ansetzen. Warum möchte man eigentlich auch lieber so einen Funkprotokoll nutzen, zum Beispiel nicht Wi-Fi? Wenn wir uns überlegen, im Home-Automation-Bereich sind die Geräte teilweise 10, 20 Jahre verbaut. Wenn wir uns jetzt weiter überlegen, wir hatten vor 15 Jahren irgendein Gerät mit Wi-Fi integriert, dann haben wir das Problem, dass wir jetzt dann irgendwelche Legacy-Devices mitschleppen würden, die noch 802.11G sprechen würden. Das wäre eher nicht so schön, und da möchte man halt dann ganz gerne eigentlich eigene Netze haben bzw. nicht so klartrennen zu anderen Geräten. ZigBee hatte ich erwähnt basiert auf 802.15.4G. Das ist relativ schön, weil es Formed-Mesh ist. Das heißt, mit jedem weiteren Gerät baut sich dieses Mesh weiter auf, wird resistenter. Es hat leider ein etwas unglückliches Protokoll. Das ist ein Gossip-Protokoll. Das heißt, es ist relativ dumm, es wird einfach alles weitergeflutet an die Information. Man kann sich ja irgendwann den Empfänger erreichen. Es funktioniert meistens auch, es funktioniert akzeptabel schnell. Es ist probkinentär. Man hat damals davon ausgegangen, die kleinen Geräte können eh kein IP sprechen. Dort müsste man sich diese Bemühungen gar nicht machen. Wir machen gleich von Anfang an etwas komplett Eigenes und nutzen das. Sehr weit verbreitet ist inzwischen die ZigBee Lightlink. Die ganzen Smart-Lightbulbs, die unterwegs sind, im hohen Automation-Bereich, sind genau dieser Standard. Dort hat man dann auch diese Kompatibilität immer gegeben, dass es pro Real-Terror-Kram verschlüsselt und so weiter und so fort. Ist relativ verbreitet an der Stelle, nutzt genau dieses Protokoll. Das heißt, der 802.15.4G. MAC und Füß eigentlich allgegenwärtig für die meisten Leute inzwischen schon. Wie ich eben schon gesagt hatte, bei Wi-Fi, warum möchte man eigentlich kein Wi-Fi nutzen? Wenn wir uns das vorstellen, ich hätte eine Fernbedienung und die nutzt Wi-Fi für meine Smart-Lightbulbs, was auch immer, dann müsste die regelmäßig im Wi-Fi wieder drin sein, die Verbindung am Leben erhalten und ähnliches, damit sie nicht rausfliegt. Sie würde relativ viel Strom verbrauchen und wir reden relativ schnell davon, dass wir Hunderte von Knoten ganz gerne hätten. Wenn ich einfach so meine Wohnung überschlage, dann bin ich relativ psychisch auf 20-30 Geräte pro Zimmer. Das sind verschiedene Sensoren, verschiedene Lichtschalter, Lichtquellen, vielleicht auch eine Messung von bestimmten Sachen, Sound und so weiter und so fort. Da sind eigentlich relativ viele Geräte gegeben. Wenn ich mir die meisten Access-Points angucke, bin ich mir nicht so sicher, ob die auch Hunderte von Geräten sauber händeln würden. Das Zweite ist, was hier natürlich nicht drinsteht, dass es kein Mesh ist. An der Stelle hätte man Probleme mit der Reichweite. Es ist mit Wi-Fi häufig ein Problem, vernünftige Coverage zu erzeugen in einer kleinen Wohnung sicher kein Problem bei größeren Installationen schwieriger. Was ich vorhin schon einmal angedeutet hatte, wenn man typischerweise sein Haus ausrichtet oder einrichtet, dann nicht für die nächsten 2-3 Jahre, sondern für 10 Jahre mindestens. Ich möchte nicht unbedingt meine ganze Hardware alle paar Jahre ersetzen, nur weil sich irgendwie ein paar kleinere Standards ändern. Und das heißt, da ist eine Co-Existenz schwierig, auch wenn es bei Wi-Fi entsprechende Widestrebungen gibt. Ich hatte es vorhin auch schon mal angesprochen. 64-Bit Header, 128-Bit Adressen, eine MTU von 1280, sind ein bisschen problematisch, das umzusetzen, insbesondere wenn man IEEE 802.154 nimmt. Und an der Stelle kommt auch 6 Lopern zum ersten Mal ins Spiel. Was man sich gedacht hat ist, man könnte ja eigentlich diesen 802.154 Mac und Fühe nutzen, man müsste nur ein paar Anpassungen betreiben. Das erste ist, naja, wir sind hier in einem lokalen Mesh, das heißt, wir wissen, dass alle unsere Geräte hier schon da sind. Das heißt, wir könnten die Header weitestgehend komprimieren, wir können viele Sachen rauswerfen, die nicht typisch für unser Anwendungsgefälte sind. Und dazu fallen auch erstmal die IPv6-Adressen ein. Wir haben ja eh schon die EUI 64-Adressen. Warum nutzen wir die nicht für unsere IPv6-Adressen? Fügen beim Rausgehen ins Internet unser globales Präfix hervor. Sobald wir reingehen, werfen wir das weg, sparen wir viele Bits an Übertragung. Denn Bits-Übertragen ist meistens relativ teuer im Vergleich zu den Verarbeitungszyklen, die wir inzwischen haben. An Stromkosten. Das heißt, wir haben sowieso ein Gateway, der uns dann das lokale Fungentaface zur Verfügung stellt. Das ist normalerweise der Übergagenpunkt ins Internet. Dort können wir die Adressen anpassen. Wir können sogar noch auf klein, kürzere Adressen gehen, die auch unterstützt werden bei den ganzen Formaten und können dabei relativ viel sparen und können es versuchen, in 127 Bits pro Frame reinzukriegen. Das ist das Erste, was man halt tut. Das Zweite ist, wir würden eigentlich ganz gerne HTTP sprechen, weil HTTP ist eigentlich ganz angenehm. Eine restvolle Architektur, eine Anfrage. Wir können das Ganze machen. Es ist schön, es hat sich durchgesetzt im Web. Es basiert aber auf Text. Ineffizient. Wenn ihr euch HTTP-Anfragen anguckt, ist das plaintext. Es sind halt viele Bytes mit dem HTTP-Geld, 1.0 und so weiter, oder 1.1. Diese ganzen Sachen sind ungünstig. Es ist relativ chatty. Es hat sehr viele Optionen spezifiziert, die für uns eigentlich klar sind. Und es ist damit ineffizient. Das Ganze auch noch auf Mikrocontrollern zu pasen, ist teuer. Das heißt, wir verbrauchen nicht nur relativ viel Energie beim Senden sondern wir müssen dann auch nochmal uns zum Kümmern, dass wir es korrekt verarbeiten. Das heißt, es ist eher ungeeignet. Und genau an dieser Stelle hat die ITF sich hingesetzt und hat daran gearbeitet, das zu ersetzen mit dem Constraint Application Protocol. Die meisten Ideen von HTTP sind eigentlich sehr gut. Aber wir brauchen eigentlich viele Dinge nicht so speziell, wie es in HTTP ist. Wir müssen nicht so flexibel sein. Wir haben Geräte, die generell besser darin sind, binary zu verarbeiten als Text und wir würden ganz gerne diesen Overhead sparen. Das heißt, warum wollen wir die Operation voll ausschreiben? Wir haben vier Operationen normalerweise. Warum setzen wir da nicht einfach 2-Bit? Warum schreiben wir explizit aus? Welche Protokollversionen wir haben, reicht es da nicht, wenn wir 4-Bits machen. Das heißt, wir gehen einfach binary und können damit relativ viel besser pasen. Die kleinen Coop-Libraries sind bei wenigen Kilobytes Flash-Verbrauch im Mikro-Controller. Das heißt, das ist eine ganz schöne Sache. Es ist nicht nur similar zu HTTP, sondern weitestgehend auch mapbar. Das heißt, es gibt Firefox-Plugins, mit denen man dann direkt die Request durchführen könnte. Man könnte auch die Request 1-2-1 ummappen. In den meisten Fällen brauchen wir aber nicht so viele Informationen, sondern wir reden hier wirklich davon, dass wir wenige Bytes normalerweise übertragen wollen. Das heißt, dort sparen wir relativ viel. Das geht so weit, dass die Min-Packet-Size von Coop bei 4 Byte liegt inzwischen. Das heißt, wenn wir die ganzen vorherigen Dinge mit einbeziehen, kommen wir auf meistens 30, 40 bis 50 Byte für ein Frame, wenn wir nur Licht an- oder ausschalten wollen mit einer UI und Dinge tun können. Das heißt, wir haben die UI-Structure übernommen von HTTP, können aber Dinge dann tun. Wir können auch dabei eine Resource-Discovery durchführen. Das ist hier die Well-known. Die wurde so spezifiziert, dass man dort dann einmal die Fähigkeiten des Geräts sich angucken kann und kann darauf dann weiterarbeiten. Und damit ist dann relativ gut zwei Wege-Kommunikation möglich. Man hat auch bestimmte Dinge rein, die ich nicht explizit aufgeschrieben habe. Reingebracht zum Beispiel, dass man Dinge bestätigen kann. Also in dem Augenblick, man möchte nicht unbedingt das Paket bestätigen, wenn man die Anfrage hat, sondern man bestätigt sie dann auf Coop-Ebene. Ja, ich habe das Paket erhalten. Ja, ich habe das ausgeführt, das passiert. Da kann man dann in dem Augenblick das Acknowledgen. Gut. Was ich vergessen habe an Slides ist, weil es eigentlich jedes Mal offensichtlich ist und ich da ein bisschen schlamppig gearbeitet habe, ist, man möchte eigentlich auch keinen TCP einsetzen. Warum will man keinen TCP einsetzen? Wenn man einen Lichtschalter hat und ich würde jetzt einen HTTP-Get drauf ausführen, stelle dich bitte ein. Dann würde das mit HTTP folgendermaßen aussehen. Hallo, ich möchte eine TCP-Verbindung mit euch aufbauen. Okay, die wird aufgebaut. Ich habe einen vollen Free-Ray Handshake. Danach schicke ich den HTTP-Anfrage, die wiederum relativ groß ist und das alles nur um diesen einbitternden Informationsübertragung schalte dich bitte an. Das heißt, dort direkt mit UDP zu arbeiten, ist sinnvoll. Coop basiert auf UDP generell. Das heißt, dass man dort zügig wenige Informationen übertragen kann und das Ganze machen kann. Die Hardware ist relativ günstig inzwischen. Die Socks sind von verschiedenen Herstellern verfügbar, von eigentlich allen Interessanten, glaube ich. Atmel, ST, TI und ein paar weitere. Und die liegen inzwischen die Socks bei ungefähr 5 Euro in Einzelstückzahlen teilweise schon. Das heißt, man kann damit relativ schöne, interessante Boards bauen und man kann damit rumspielen. Man kann damit Dinge bauen, ohne dass man jetzt irgendwelche Patente einhalten muss oder andere Sachen. Und die können halt auch wirklich Ende zu Ende im Internet kommunizieren. Die Slides, die ich leider auch nicht hinzugefügt habe, ist DTLS. Das heißt, dass man mittels DTLS, weil es ja UDP ist, einzelne Pakete verschlüsseln kann und da halt auch vernünftige Sicherheit aufbauen kann, vergleichbar zu TLS. Die Sicherheitsprimitiven müssen mindestens AES128 unterstützen. Das schreibt der MAC vor, bei 802.154. Und dort setzt man dann halt typischerweise auch auf. Die heutigen Socks können dann halt auch die System Ownerships können. Normalerweise ECC inzwischen und auch RSA 2048. Das heißt, dort gibt es auch eigentlich keine Entschuldigung, warum sie nicht vernünftige Krypto fahren können. Und es sind eigentlich auch die meisten Bausteine schon vorhanden. Die aktuellen System Ownerships sind sogar so weit, dass sie ja wissen, dass sie im 2,4 GHz-Bereich normalerweise funken müssen. Und eine ähnliche Anforderung hat Bluetooth LE. Und auch dort gibt es inzwischen den 6-Low-Pan-Adaptation Layer. Ich meine, 2015 oder 2016 veröffentlicht, dass man dort dann auch ein Mapping draufführen kann und auch Bluetooth LE-Geräte einbinden könnte und direkt IP darüber sprechen könnte. Andere Layer, die in der Arbeit sind, sind NFC. Und es wurde mal diskutiert, ob man SmartCards auch anbinden sollte über so etwas. Klingt manchmal absurd, aber es wäre halt ein Läher da drunter zu haben und nur einen Format sprechen zu müssen. Wie ich vorhin gesagt hatte, wollte ich das Ganze auch eher kurz halten bzw. mit einer Vorbereitung nicht so weit gekommen, wie ich gehofft hatte. Falls irgendjemand Fragen hat, gerne hier. Auch gerne nachher noch. Und ich hoffe, es war mehr oder minder interessant. Ich würde mich freuen, wenn mehr Leute an solchen Dingen arbeiten würden. Es gibt inzwischen auch einige interessante Bewegungen, dass es auch in diesem Bereich rauskommt mit den entsprechenden Funktionsstellen. Es gibt verschiedene Betriebssysteme, die entwickelt werden. Ich weiß nicht, ob einige der Riot-Entwickler hier dabei sind. Da sind auch einige Leute im Umfeld. Ich vermute auch im Chaos-Umfeld aktiv, die sich auch beim Kongress regelmäßig treffen. Vielen Dank für eure Aufmerksamkeit und ich hoffe, es hat euch mehr oder minder gefallen. Ich baue hier schon einige Zeit auch mit Six-Low-Pan und so weiter. Wir verwenden Conticky OS. Das ist so eine und 8-bit Mikro-Kontroller, so Art-Meld-Dinger. Die haben halt den Vorteil, dass das Power-Saving sehr, sehr schnell geht und sehr schnell wieder aufwacht. Das heißt, der kann 8x pro Sekunde ein Paket schicken und immer die 125 Mikrosekunden dazwischen 15 Millisekunden dazwischen schlafen und wieder aufwachen. Das heißt, das macht nichts, wenn der nur eine 8x Sekunde schläft und man kommt auf sehr, sehr lange Batterie-Lebensstoren, also mit 2,3 Batterien ein halbes Jahr oder so. Wenn man das mit WLAN vergleicht, mit 2,3 Batterien kommt man vielleicht den Nachmittag durch. Mich würde interessieren, wo du, wie weit das ist mit TLS, weil wir noch keine Unterstützung haben. KonTiki hat das auch noch nicht und wieder so der Stand deiner Entwicklung ist und dann würde ich auch gerne, dass wir können ja austauschen. Erstmal, ich bin mir nicht sicher, wie weit der DTLS-Unterstützung inzwischen ist. Ich habe dieses Weitesgehen aus den Augen verloren vor ein paar Jahren. Ich weiß, dass es zu Referenzimplementierungen gibt an meiner Universität Bremen machen wir. Dazu verschiedene Dinge. Das ist ein Tiny-DTLS-Library, die von uns gepflegt wird. Und ich meine, dort ist es schon relativ weit. Der Stichwort 8-Bit-Mikro-Controller ja, ich bin inzwischen immer auf 32 Bit-Mikro-Controller, was aber ja nicht so viel Unterschied macht an der Geschichte. Bei der Batterie-Lebenszeit würde ich noch mal anmerken, wir reden hier meistens von Jahren, die man anpeilt an Batterie-Lebensdauer. Und genau, und hier sind wir bei 8 Mal pro Sekunde senden und die Sorgs haben sich weitestgehend weiterentwickelt. Ich habe mit den 8 Bit-Mikro-Controllers vor 7, 8 Jahren mal gearbeitet und inzwischen sind die Aufnahmen, es wurde drastisch besser bei den entsprechenden Sorgs. Ich glaube, Faktor 4, Faktor 5 sind sie inzwischen effizienter beim Senden Genau, also der Einwurf war nochmal, dass es deutlich mehr Strom raucht, der 32 Bit-Core, nichtsdestotrotz wird daran gearbeitet und ja, wir reden hier wirklich davon, dass wir von 8 Bit bis hoch Geräte unterstützen und deshalb ist das eigentlich auch ein ganz schönes Testbed aus meiner Sicht, aber wie gesagt, Detail-S müsste ich noch mal reinschauen, ich weiß, dass es die Tiny Detail-S gibt, es gibt verschiedene andere Implementierungen, ich weiß, dass Leute dran sind bei uns, aber dann kann ich dir dort nicht sagen, müsste ich aber noch mal nachschauen und kann ich dann sicher dazu dann verlinken. Wenn das gelbe Licht leuchtet, ist er aus. Jetzt ja, Frage zu diesem Co-Up. Du hast vorhin erwähnt, dass es eventuell Firefox-Plugins gibt oder geben könnte, die das sprechen, aber das heißt doch auch, dass es dann zwei Seiten von diesem Protokoll geben muss, eine, die auf IP aufsetzt und eine das auf 6 Low-Pan aufsetzt und Gateway ist dazwischen. Wie muss ich mir das vorstellen, so ein Gateway? Nein. Also das erste ist, es gibt diese Plugins, es gab diese Plugins schon vor sieben Jahren, das heißt, ich weiß nicht, wie weit die weitergeführt wurden und weil die Plug-in, es wurde gerade ergänzt, wurde leider nicht weiterentwickelt, weil das Firefox die AP geändert hat und dabei wurde dann die Weiterentwicklung unterbrochen. Die generell ist es nur das Layer 7 Protokoll, das heißt, in dem Moment, wenn ich das Paket, also wenn ich die Anfrage schreibe, ich schreibe dann anstelle von HTTP nutze ich Co-Up. Ich benutze aber immer noch IPv6, um das Gerät direkt anzusprechen. Dieses Paket wird vom Gateway normalerweise direkt durchgereicht und wenn es Co-Up ist, ist das alles kein Problem. Wenn man eine HTTP zu Co-Up Mapping macht, muss man dazwischen ein Gateway einfügen und der würde den typischen HTTP-Get-Request umschreiben auf einen Co-Up-Get-Request, was insbesondere heißen würde, die ganzen Text, also den ganzen ANSI-Text löschen und dafür dann halt die entsprechenden Bits setzen, die URI einfügen und das dann weiterzuschicken. Das Gateway tritt den Demaumblick in Kraft, wenn eine Fragmentierung stattfindet insbesondere. Das heißt, wenn ich jetzt ein zu großes Paket schicken würde an ein 6-Low-Pan-Device wird das Gateway diesen Request erhalten, wird das Ganze in kleinere Pakete umschreiben und das dann weiter senden. Es wird aber den Inhalt an sich nicht anfassen. Das heißt, dort wird nur eine Fragmentierung stattfinden. Das heißt, du wirst immer das gleiche Paket kriegen. Die Gateway sind weitestgehend dumm, sag ich jetzt mal, wenn man das mal vergleicht mit den typischen Trattfri und ähnlichen Lampen, wo du eigentlich ein Device hast, wo dann die ganzen Anfragen nochmal auf das interne Protokoll in diesem Fall et cetera umgeschrieben wird. Beantwortet das weitestgehende eine Frage? Größtenteils. Das, was nicht beantwortet worden ist, ist der Teil vielleicht habe ich noch nicht gut formuliert aber ist die Art der Umschreibung in diesem CoA-Protokoll spezifiziert oder ist das rein implementationsabhängig? Ich meine, dass es spezifiziert sein müsste. Ich müsste aber nochmal genau nachschauen. Es müsste eigentlich 1 zu 1 direkt um zu mapen sein und ich meine, das war auch eines der Ziele beim Protokollentwurf. Wie gesagt, die Protokolle wurden bei der IETF entworfen. Das heißt, die hatten von vornherein auch vor Augen. Danke. Ja, es gibt hier noch einen Nachtrag. Also, das Protokoll ist so designed, dass man relativ einfach Proxies machen kann. Also du brauchst gar kein Gateway in dem Sinn, sondern du kannst eigentlich ein HTP auf CoA-Poxie machen und es ist auch in Protokoll spezifiziert, wie das funktioniert. Und damit kann man relativ einfach das tun, aber man kann halt nicht mit einem normalen Browser trotzdem irgendeine Restanwendung schreiben müssen. Und dann ist natürlich die Frage, es gibt gute Libraries in allen Programmiersprachen, also Python, C und whatever, ob man dann nicht gleich statt über den Proxy zu gehen direkt CoA abspricht, wenn man sowieso die Restanfragen so machen muss. Und sonst, also meine Erfahrung ist, dass es eigentlich sehr wenig Proxies gibt, sondern dass man direkt mit dem Device rede. Ein wichtiger Punkt, den ich nicht erwähnt habe vorhin, ist, es gibt eigentlich Implementierung in fast allen Programmiersprachen. Dort gibt es auch regelmäßige Plug-Tests, wo man auch guckt, wie weit sind die Implementierung und ähnliches. Man fährt halt unter dem ITF-Motto Rough Consensus und Running Code. Und das hat sich eigentlich sehr gut bewährt und man hat eigentlich auch gesehen, wie schnell sich das Ganze entwickelt hat. In der Zeit, wo ich primär drin war, und wir haben halt festgestellt, so das ist ein schönes Neuer Karm als Studenten. Wir haben geglaubt, das ist die Zukunft. Ein paar Jahre später haben wir Leute erzählt, ja, Google möchte jeder Glühbirne eine IPv6-Adresse geben, geben... Ja, das haben wir euch versucht zu erklären die letzten Jahre, wie das funktionieren kann. Und wir sehen jetzt mit Radfli die ersten kommerziellen Produkte, die CoAb und die Gateway direkt sprechen. Das heißt, das kommt so langsam aber sicher, ist aber eigentlich ein sehr schöner Stack aus meiner Sicht für Internet-of-Things-Geräte und andere Dinge, wie kleinere Messenger. Wie sind der Stand der Dinge bei den SIBOA-Implementierungen, weil das letzte Mal wie ich da hingeschaut hat, waren vor allem tolle Kutierungen, aber die Implementierungen waren irgendwie mäßig brauchbar noch für ein Bandit-Geräte, die ausgekommen sind und zu geschichten. Bin ich gerade überfragt, müsst ihr noch mal nachschauen. Können wir aber nachher noch mal gucken. Wie schaut's mit Sicherheit an sich bei diesem ZigBee-Projekt, ZigBee-Protokoll aus? In der Theorie gut. Sie verwenden standardisierte vernünftige Krypto an vielen Stellen. Sie haben eigentlich auch sehr viel Energie reingesteckt, um andere Mitbewerber auszuschließen, indem sie das Protokoll veröffentlicht haben wie bei ZLA, aber die Kies nicht. Alles in allem ist das aber grausam. Das hängt immer sehr stark von der Implementierung ab. Es ist eine Frage, ob Downgrade-Attacks möglich sind, aber an und für sich kann man, oder finde ich, dass es vergleichbar ist, wie mit Wi-Fi. Man kann die entsprechenden Channels, wie bei erst 128, dort kann man theoretisch viel machen. Aber ZigBee an sich, finde ich eigentlich eher, ist ein Mixback. Also, vielleicht da zum Input, ZigBee arbeitet an einem neuen Protokoll, nächste Version, und die basiert auf ZigSlowPan. Das sind auch viele von den ZigBee, die Firmen, die in ZigBee aktiv sind, im ZigSlowPan-Bereich sind. Das heißt, man kann davon ausgehen, dass das abgelöst wird. Allerdings wollen die dann wieder oberhalb von IPv6 ihren eigenen proprietären Stack haben. Ob sich das durchsetzt, darf man gespannt sein, weil es eben Co-Up inzwischen gibt, weil es auf Basis von Co-Up-Mesh-Routing- Protokolle gibt, die auch von der IETF spezifiziert sind und man daher davon ausgehen muss, wird. Also, ich würde jetzt, wenn ich was neu entwickle, das nicht auf ZigBee Basis tun. Und zur Verschlüsselung eben, es gibt das DTLS, also für Co-Up ist das komplett spezifiziert. DTLS war zu Zeiten von 1.2 und funktioniert aber mit 1.3 TLS, im Prinzip auch 1 zu 1. Von daher sehe ich dort, es gibt so dieses eine Rehper, wo sie dieses Lightlink auseinandergenommen haben, die Philips Hue-Lampen gehackt haben, ist schon 1,5 Jahre her oder so, das haben vielleicht einige von euch verfolgt und da sind 2 Sachen rausgekommen, schon 2015 wurde der Pairing-Key, wenn ich ein neues Device in mein Netz bringen will, muss das ja irgendwie die Krypto kriegen. Da gibt es einen fixen Pairing-Key, den alle Members vom ZigBee-Konsortium gekriegt haben. Der ist 2015 auf Twitter gelegt worden. Nonah und Philips hat ein Upgrade-Key um Firmware-Upgrades zu machen und dieser Upgrade-Key ist vom selben Twitter-Account 2017 gelegt worden, nachdem es eben dieses Paper gab über diesen IoT-Warm-Idee, die haben eben gesagt, wir können eine Lampe vom Nachbarn klauen, in unseren Netz bringen, Resetten und dann kann ich deren neue Firmware aufspielen und dann infiziert sie alle anderen Lampen im Umkreis und so vorbereitet sich das immer wieder aus, gemacht haben sie es nicht, aber es zeigt, dass die Security von dem Zeug jetzt nicht so gut ist, wobei die Attacke schwierig ist, also die haben eine Side-Channel-Attacke auf die Krypto gemacht und die Leute, die damit involviert waren, der eine Autor ist der Adi Shamir, das ist das S in RSA. Die haben schon gewusst, was sie tun, aber wenn mal Geist aus der Flasche ist, das kriegt man ja nicht mehr rein. Da kann man noch ergänzen, also ich finde die Ergänzung super. Es gab Packet-in-Packet-Attacken auf SIGBI und 802.154 von Travis Goodspeed und ähnlichen. Das heißt, wenn du im unverschlusseten Wi-Fi warst, konnte ich dir spezielle Packets teilweise schicken, die dann für ein SIGBI-Device aussehen, die SIGBI und damit dann wieder weiter vom Wi-Fi SIGBI-Device ist angreifend über die Luftschnittstelle. Dieser Angriff, der gerade erklärt wurde von Shamir, ist einer der Schwachpunkte, die zum Beispiel bei den Trattfilampen vorhanden sind. Ein bekannter von mir hat in einer Bachelorarbeit die Trattfilampen untersucht und das war eine der beiden Schwachstellen, die er gefunden hat und man kann lange darüber diskutieren, ob das ein gutes Ergebnis ist, dass er nur zwei Schwachpunkte gefunden hat oder ob das eigentlich schlimm ist. Aber feststeht, dass Ikea relativ solide da etwas gebaut hat schon und wie es weitergeht. Bei SIGBI müsste man vielleicht auch nochmal sagen, dass mit Smart-IP war ja auch schon vor ein paar Jahren einmal in der Mache von SIGBI, dass sie ihren ganzen Standard nochmal überarbeiten wollten für Co-op vor ungefähr neun Jahren ist. Also, er soll jetzt kurz vor dem Release sein. Genau. Für MAMBA ist er schon verfügbar, wurde gerade gesagt und finde ich einfach noch eine Anmerkung. Ich glaube, in diesem Paper von Shamir und Konsorten steht eben eins der Probleme, dass SIGBI hat, dass sie ihren Standard hinter verschlossenen Türen machen, im Gegensatz dazu, dass SIGBI in den letzten Jahren noch ein paar Jahre in der Mache gefordert ist, nämlich mit weltweiter Beteiligung von den besten Leuten, die es in dem Bereich gibt und dass das natürlich auch zu diesen Security-Problemen führt. Ja. Und es kann sich auch jeder daran beteiligen. Also, es passiert ziemlich viel. Gibt es weitere Fragen? Anmerkungen. Was ist das, dass das irgendwie dann ein signifikantes Protokoll-Update bekommt? Bleibt das, sind wir jetzt an das SIGBI gefesselt, so wie wir es jetzt kennen? Also, wenn wir schon eine Infrastruktur uns gebaut haben. Es ist schwierig zu sagen, weil man an, also man könnte, dass das auf 800, 250 und 4 aufsetzt, könnte man natürlich teilweise anderes Decks ausrollen, wenn die passenden Chips vorhanden sind. Also, die Updates sind immer schwierig von Konsumenten Devices kaputtzumachen. Ist auch immer schwierig zu rechtfertigen. Alleine, was für Probleme Phillips mit der Highlight hat, teilweise, wo dann firmware Updates 2 Stunden dauern pro Glühbirne, wie Scott Hensel mal mal beschrieben hat, sind eigentlich nicht tragbar und auch alles andere als cool. Allerdings, wenn wir uns an die Nest-Rauchmelder machen und diese ganze Home- Automation-Sachen, die hatten auch die passenden Chips drin. Das heißt, es könnte relativ zügig vieles umgeschrieben werden. Die Infrastruktur war und ist weitestgehend teilweise schon vorhanden. Auch mit universellen Geräten. Teilweise müsste dann nur das Gateway ausgetauscht werden. Aber wie gesagt, SIGBI-Geräte umprogrammieren ist halt ein bisschen schwierig. Wir haben mit allen Herstellern zusammen arbeiten, die weitestgehend dahinter sind. Es ist schwierig. Die Frage war gerade, ist die Kurze vergleichbar? Wir haben mit 64 Kilobyte Flash-Geräten angefangen und wir konnten Co-op und SIG Slow-Pen darauf ausführen. Das ist vergleichbar weitestgehend. Inzwischen mit 128 Kilobyte Flash und 16 Kilobyte RAM hatten wir in sehr bequeme Entwicklung und wir sind dort nicht mehr limitiert. Inzwischen haben die Socks 256 Kilobyte Flash und dort sind viele Möglichkeiten drin, von denen wir vor acht Jahren geträumt haben. Wir haben zum Beispiel mit den 256ern Chips ein Over-the-Air Update gemacht, der lang nicht so lange dauert und erfahrungsgemäß ist der SIGBI-Stack sogar ein bisschen größer, als wenn du Co-op plus SIG Slow-Pen hast. Du kannst sogar Co-op mit SIG Slow-Pen plus TCP machen. In diesen Socks ist auch implementiert. Den Conti-GOS passt immer noch in unter 64K rein, aber TCP ist normalerweise was, was man halt nicht will in dem Bereich. Nein, eben DTLS und TLS haben wir noch nicht und das ist ... Da wird man halt größer in dem Augenblick. Da hatten wir mit 80 Kilobyte Socks gearbeitet. Es gibt ja noch Thread oder Open Thread von Google, also ehemals Nest und jetzt ist es Google. Das baut auf auf der 80254 Hardware. Wie ist da das Verhältnis zu? Ist das ein nettes Open-Source-Projekt, aber Sie halten sich nicht an Standards und machen was Sie wollen? Die Features hören sich net an so mandatory encryption. Ich habe Meinungen dazu, aber die sind nicht wirklich qualifiziert. Die sind noch nicht qualifiziert. Also kurz zu was die Nest-Leute machen ist sie setzen zumindest auf Six-Low-Pan und auf irgendeine Verschlüsselung, das ist glaube ich noch nicht so ganz spezifiziert, weil du hast das Problem, dass IPsec zu groß ist, insbesondere das ganze Key-Management-Zeug das wird's da nicht spielen auf diesen Embedded-Devices. Die Best-Bed ist zurzeit Detail-S. Die Nest-Leute streiten glaube ich immer noch, was sie auf der Applikationsschicht machen. Also Co-op haben sie sich bis jetzt noch nicht dazu durchgerungen, weil es halt da so zwei Fraktionen gibt oder mehr, die irgendwas anderes wollen insbesondere habe ich schon erwähnt, wie halt einen eigenen Stack und so. Aber zumindest mal die unteren Schichten sind kompatibel. Das ist schon mal ganz gut und die machen Interoperabilitäts-Tests mit vielen Devices. Also mit hunderten Devices und das funktioniert. Und das ist zumindest mal eine ganz nette Sache. Ich sehe da halt ein Silo entstehen. Das ist halt mein großes Problem. Weshalb ich ein bisschen kritisch bin, aber es sind gute Ansätze dabei. Was meinst du damit Silo entsteht? Dass du ein Wendalock in gemacht wird, dass man ein Memberallianz sein muss, um die ganze Spezifikation zu kriegen. Es war, als sie angefangen haben, nicht sehr freundlich für Entwickler. Das kann sich inzwischen geändert haben, aber ich habe mich damals dann rausgehalten, nachdem ich gesehen habe, dass es verschiedene Hürden gab, an die Dokumente heranzukommen. Ja, es gibt inzwischen Open Source dafür, ja. Und die unterstützen es auch, das muss man auch loben dazu sagen. Hast du eine Meinung zu MQTTSN? Nein. Dann danke ich allen. Insbesondere auch allen, die beigetragen haben. Wie gesagt, ich finde, es ist ein interessantes Feld. Ich würde mich freuen, wenn mehr Hacker Space sich damit ein bisschen auseinandersetzen. Es ist günstig, man kann viele Sachen machen und es ist standardisiert, und man muss da nicht eigene Dinge an vielen Stellen neu erfinden. Deshalb, vielen Dank. Und das Schöne ist der Heck.