Warum ich Shorium aufbaue

Über meine eigenen Unternehmen schreibe ich hier normalerweise nicht.

Diesmal habe ich einen guten Grund, eine Ausnahme zu machen.

In den letzten Monaten ist ein großer Teil meiner Arbeit in Shorium geflossen, ein Cybersicherheitsunternehmen, das ich als Co-Founder und CTO aufbaue.

Ein interessanter Ort, an dem ich mich da wiederfinde, nach fünfundzwanzig Jahren in Produktdesign, Technologie und Mensch-Computer-Interaktion.

Doch je länger ich daran arbeite, desto klarer wird mir, dass die Probleme, die wir lösen wollen, eng mit denen verwandt sind, die mich meine ganze Laufbahn hindurch beschäftigt haben.

Nur dass es diesmal um Kryptografie, vernetzte Geräte und eine ziemlich unbequeme Frage zur Zukunft des digitalen Vertrauens geht.

Ein Produkt muss nicht kaputtgehen, um unsicher zu werden

Denken Sie an ein vernetztes Produkt.

Das kann ein Zahlungsterminal sein, ein Industriesensor, ein Medizingerät oder ein Auto.

Wenn wir mit solchen Produkten umgehen, sehen wir, was sie tun. Die Systeme, die ihren sicheren Betrieb ermöglichen, sehen wir selten. Hinter der Oberfläche liegen Hardware, Firmware, Software, Zertifikate, kryptografische Schlüssel, Identitäten, Zulieferer und Update-Mechanismen.

All diese Komponenten hängen voneinander ab.

Und viele dieser Abhängigkeiten beruhen auf Annahmen, die getroffen wurden, als das Produkt ursprünglich entworfen wurde.

Stellen Sie sich nun vor, dieses Produkt läuft fünfzehn Jahre lang.

In dieser Zeit laufen Zertifikate ab, Algorithmen veralten, Zulieferer wechseln, Schwachstellen werden entdeckt und Vorschriften ändern sich. Das Produkt funktioniert womöglich weiterhin einwandfrei. Es schaltet sich ein. Es verbindet sich. Es erfüllt seine Funktion. Aus Sicht der Nutzenden hat sich nichts geändert.

Doch darunter gibt es die Bedingungen, die es vertrauenswürdig gemacht haben, vielleicht gar nicht mehr.

Ein funktionierendes System ist nicht unbedingt ein vertrauenswürdiges System.

Einen großen Teil meiner Laufbahn habe ich damit verbracht, Produkte zu gestalten, die verständlich und benutzbar bleiben müssen, während sie komplexer werden.

Eines habe ich dabei gelernt: Komplexität verschwindet nicht, nur weil wir sie nicht mehr zeigen. In der Sicherheit kann diese verborgene Komplexität zu einem ernsten Problem werden.

Vor allem dann, wenn niemand klar erklären kann, was wovon abhängt.

Quantencomputer sind nicht der eigentliche Ausgangspunkt

Sobald die Rede auf Post-Quanten-Kryptografie kommt, wandert das Gespräch meist sofort zu den Quantencomputern.

Wann werden sie leistungsfähig genug sein, um die heutige Kryptografie zu brechen?
In fünf Jahren? In zehn? In zwanzig?

Ich finde die Frage interessant, aber aus technischer Sicht würde ich nicht dort anfangen. Wir wissen bereits, dass weit verbreitete Public-Key-Kryptosysteme migriert werden müssen.

NIST hat 2024 seine ersten Standards für Post-Quanten-Kryptografie veröffentlicht. Die Europäische Union hat eine koordinierte Roadmap aufgestellt, mit 2030 als wichtigem Meilenstein für Anwendungsfälle mit hohem Risiko.

Der Übergang hat begonnen, ganz gleich, wann ein ausreichend leistungsfähiger Quantencomputer verfügbar sein wird.

Und die Schwierigkeit besteht nicht einfach darin, einen neuen Algorithmus auszuwählen.

Stellen Sie sich vor, Sie müssten die Kryptografie eines Industriegeräts austauschen, das bereits in Tausenden von Installationen im Einsatz ist.

Seine Firmware hängt womöglich von einem bestimmten Signaturverfahren ab.
Seine Hardware unterstützt den neuen Algorithmus vielleicht nicht.
Seine Identität kann von Zertifikaten abhängen, die über eine bestehende Infrastruktur ausgestellt wurden.
An seinem Update-Prozess sind möglicherweise mehrere Zulieferer beteiligt.

Die Änderung einer einzigen Komponente kann die gesamte Kette betreffen.

Eine solche Migration lässt sich nicht angehen, als würden Sie eine Anwendung auf Ihrem Laptop aktualisieren.

Und Sie können schon gar nicht davon ausgehen, dass sich jedes Gerät zurückrufen, ersetzen oder vom Netz nehmen lässt. Wir versuchen, grundlegende Sicherheitsmechanismen in Systemen zu ändern, die weiterlaufen müssen.

Kryptografische Kontinuität

Genau hier kommt Shorium ins Spiel.

Der Name geht auf den Shor-Algorithmus zurück, der gezeigt hat, wie ein ausreichend leistungsfähiger Quantencomputer weit verbreitete Public-Key-Kryptosysteme brechen könnte.

Mir gefällt die Idee, ein Unternehmen nach dem Algorithmus zu benennen, der das Problem offengelegt hat.

Denn wir bauen kein Unternehmen auf der Vorstellung auf, dass Kryptografie niemals bricht. Wir bauen es auf der Vorstellung auf, dass Vertrauen den Wandel überstehen muss.

Der Schwerpunkt von Shorium ist kryptografische Kontinuität.

Konkret entwickeln wir eine Plattform, die dazu dient, die kryptografischen Vertrauensbeziehungen in vernetzten Produkten aufzuspüren, zu modellieren und zu verwalten.

Das zentrale Konzept nennen wir Trust Twin.

Stellen Sie es sich als lebendiges Modell der kryptografischen Abhängigkeiten vor, auf denen ein Produkt ruht.

Nicht bloß ein Inventar von Zertifikaten oder Algorithmen.

Sondern eine Darstellung davon, wie diese Elemente zueinander in Beziehung stehen.

Welcher Schlüssel signiert welche Firmware?
Welches Zertifikat begründet welche Identität?
Welche Komponenten hängen von einem bestimmten kryptografischen Mechanismus ab?
Was passiert, wenn ein Algorithmus als veraltet eingestuft wird?
Was ändert sich, wenn ein Zulieferer eine Komponente ersetzt?
Und wie lässt sich nachweisen, dass ein Produkt nach diesen Änderungen vertrauenswürdig bleibt?

Diese Fragen sind schwer zu beantworten, wenn die Informationen über Entwicklungsteams, Fertigungssysteme, Zulieferer und Dokumentation verteilt sind.

Unser Ansatz gliedert sich in vier Fähigkeiten: Observe, Connect, Simulate und Orchestrate.

Zuerst die relevanten kryptografischen Signale aufspüren.
Dann die Beziehungen zwischen ihnen rekonstruieren.
Diese Beziehungen nutzen, um die möglichen Auswirkungen von Änderungen zu bewerten.
Und schließlich die Teams dabei unterstützen, den Übergang zu planen und zu koordinieren und zugleich festzuhalten, was geschehen ist.

Das Ziel ist nicht, noch ein Dashboard voller grüner Anzeigen zu produzieren.

Es geht darum, kryptografische Kontinuität zu etwas zu machen, das Ingenieurinnen und Ingenieure verstehen, bewerten und nachweisen können.

Eine wichtige Unterscheidung gehört hierher: Das ist die Architektur und die Produktrichtung, auf die wir hinarbeiten. Wir sind ein Unternehmen in der Frühphase, und ich will eine technische Vision nicht mit einem fertigen, validierten Produkt verwechseln.

Aber das Problem ist real, und die Richtung ist klar.

Warum ein Produktdesigner an Kryptografie arbeitet

Ich bin kein Kryptograf.

Und ich habe nicht vor, so zu tun.

Bei Shorium gibt es Leute, die seit Jahren in der kryptografischen Forschung arbeiten. Meine Aufgabe ist eine andere. Ich habe rund fünfundzwanzig Jahre damit verbracht, digitale Produkte, Oberflächen und komplexe Systeme zu gestalten.

Ich habe in verschiedenen Branchen gearbeitet, von digitalen Diensten über Unternehmenssoftware bis zu Embedded-Cybersicherheit. Drei Jahre lang war ich Design Lead bei Exein und arbeitete dort an Produkten in einem Umfeld, in dem das Verhältnis von Hardware, Software und Sicherheit besonders wichtig ist.

Und in all diesen Jahren bin ich immer wieder beim selben Problem gelandet.

Technologie wird nützlich, wenn Menschen verstehen, was sie damit tun.

Das mag selbstverständlich klingen.

In der Praxis ist es das nicht.

Ich habe technisch anspruchsvolle Produkte gesehen, die unnötig schwer zu bedienen waren, weil ihre Architektur für die Ingenieure, die sie gebaut hatten, Sinn ergab, nicht aber für die Menschen, die für ihre Nutzung verantwortlich waren.

Ich habe auch das Gegenteil gesehen: Oberflächen, die einfach aussehen sollen und dabei so viel Komplexität verbergen, dass die Nutzenden nicht mehr verstehen können, was tatsächlich passiert.

Beides ist nicht gerade gutes Design.

Und in der Cybersicherheit kann beides gefährlich werden.

Stellen Sie sich vor, Sie sind für die Sicherheit mehrerer Tausend vernetzter Geräte verantwortlich.

Ein kryptografischer Algorithmus muss ersetzt werden.

Sie haben eine Liste betroffener Produkte, mehrere Entwicklungsteams, Zulieferer, Compliance-Anforderungen und eine Frist. Was Sie nicht brauchen, ist eine schöne Oberfläche, die Ihnen sagt, dass etwas nicht stimmt.

Sie müssen die Folgen Ihrer Entscheidungen verstehen.

Welche Geräte sind betroffen?
Was lässt sich ändern?
Was nicht?
Was passiert, wenn Sie eine Abhängigkeit vor einer anderen migrieren?
Können Sie nachweisen, dass das System danach sicher bleibt?
Genau hier sehe ich die Verbindung zwischen meinem Werdegang und dem, was wir aufbauen.

Meine Verantwortung als CTO besteht nicht einfach darin, dafür zu sorgen, dass wir die richtigen Technologien wählen.

Es geht darum, eine Architektur mitzubauen, in der wissenschaftliche Korrektheit, technische Randbedingungen und menschliche Entscheidungen nebeneinander bestehen können.

Die Kryptografie muss solide sein.
Die Software muss zuverlässig sein.
Und die Menschen, die sie betreiben, müssen genug vom System verstehen, um fundierte Entscheidungen zu treffen.

Das löst man nicht, indem man am Ende der Entwicklung ein hübscheres Dashboard ergänzt.

Es muss die Architektur von Anfang an prägen.

Komplexität verständlich machen heißt nicht, sie zu verstecken

Es gibt einen Grundsatz, dem ich im Produktdesign seit Jahren folge.

Lassen Sie etwas nicht einfach aussehen, indem Sie die Informationen entfernen, die Menschen brauchen.

Machen Sie es verständlich.

Ich halte diese Unterscheidung gerade jetzt für besonders relevant, da immer mehr Softwareprodukte Automatisierung und KI in immer komplexere Arbeitsabläufe einführen.

Wir sind sehr gut darin geworden, Systeme Antworten produzieren zu lassen.

Nicht immer ebenso gut sind wir darin, Menschen verstehen zu helfen, woher diese Antworten kommen, auf welchen Annahmen sie beruhen oder was passiert, wenn sich diese Annahmen ändern. Bei einer Consumer-Anwendung führt das vielleicht zu einem frustrierenden Erlebnis. Bei einem sicherheitskritischen System können die Folgen weit ernster sein.

Bei Shorium prägt das, wie ich über den Trust Twin nachdenke.

Ein Modell kryptografischer Abhängigkeiten ist nur dann nützlich, wenn es jemandem hilft, über das System nachzudenken.

Es reicht nicht, eine Beziehung aufzuspüren.

Wir müssen ihren Ursprung verstehen, ihren Kontext und die Belege, die sie stützen.

Ändert sich eine Abhängigkeit, sollte das System dabei helfen, die Folgen zu erklären.

Wird eine Empfehlung ausgesprochen, brauchen die Menschen, die danach handeln sollen, genug Informationen, um sie zu bewerten. Und wenn eine Entscheidung fällt, muss es eine Möglichkeit geben, nachzuvollziehen, was geschehen ist. Dieser letzte Punkt ist wichtiger, als es scheinen mag.

In der Cybersicherheit kann es genauso wichtig sein, eine Entscheidung sechs Monate später erklären zu können, wie sie von vornherein richtig zu treffen.

Deshalb finde ich die Schnittstelle von Produktdesign, Softwarearchitektur und Sicherheit so interessant.

Gutes Design ist keine Dekoration, die man auf die Technik aufträgt.

Es ist ein Teil dessen, wie ein System sein eigenes Verhalten vermittelt.

Und manchmal macht es den Unterschied zwischen dem Besitz von Informationen und der Fähigkeit, danach zu handeln.

Die Menschen hinter Shorium

Einer der Gründe, warum ich mich auf diese Herausforderung eingelassen habe, ist das Team.

Danilo Bontà, unser Founder & CEO, arbeitet seit mehr als fünfzehn Jahren in den Bereichen Cybersicherheit und internationale Technologie. Zu seinen Erfahrungen gehören der Aufbau des globalen Partner-Ökosystems von Moodle, die Arbeit im asiatisch-pazifischen Raum und die Zusammenarbeit mit Institutionen wie der NATO und Regierungsorganisationen.

Dan und ich haben schon früher bei Exein zusammengearbeitet.

Wir kannten also die Art, wie der andere an Probleme herangeht, und uns verband das Interesse daran, was passiert, wenn Cybersicherheit in echten Produkten funktionieren muss statt in theoretischen Architekturen.

Dariia Porechna, Co-founder & Chief Scientific Officer, kommt aus einer ganz anderen Richtung.

Sie ist Post-Quanten-Kryptografin und war sechs Jahre bei Wolfram Research, wo sie mit Stephen Wolfram zusammenarbeitete und kryptografische Funktionen für die Wolfram Language entwickelte. Außerdem ist sie Mitautorin von SILMARILS, einer Konstruktion für digitale Post-Quanten-Signaturen. Dariia bringt die wissenschaftlichen Grundlagen mit, die ein Produkt wie Shorium braucht.

Zu unserem erweiterten Team gehören außerdem kryptografische Forscherinnen und Forscher, Ingenieurinnen und Ingenieure sowie Menschen, die dafür verantwortlich sind, aus dieser Forschung etwas zu machen, das wir bauen und betreiben können.

Ich arbeite gern in einem solchen Umfeld.

Menschen, die dasselbe Problem mit unterschiedlichen Denkmodellen angehen, stellen in der Regel unterschiedliche Fragen.

Eine Kryptografin fragt vielleicht, ob eine Konstruktion mathematisch solide ist.

Ein Ingenieur fragt vielleicht, ob sie sich innerhalb der Grenzen eines bestimmten Geräts zuverlässig umsetzen lässt.

Ein Produktdesigner fragt vielleicht, ob die Person, die für dieses Gerät verantwortlich ist, verstehen kann, was als Nächstes geschehen muss.

Alle drei Fragen zählen.

Und als CTO gehört es zu meiner Verantwortung, dafür zu sorgen, dass daraus nicht drei getrennte Gespräche werden.

Warum das auch ein Brownfield-Problem ist

Es gibt noch einen weiteren Grund, warum ich hier über Shorium schreibe.

Der Großteil der Technologiebranche spricht gern über neue Dinge.

Neue Architekturen. Neue Frameworks. Neue Infrastruktur. Neue Produkte.

Wir neigen dazu, technologischen Fortschritt so zu beschreiben, als begänne alles mit einer sauberen Umgebung und einem perfekt entworfenen System.

Das tut es selten. Echte Organisationen haben bestehende Produkte. Bestehende Infrastruktur. Bestehende Zulieferer, Prozesse, Zertifizierungen und technische Entscheidungen, die vor Jahren getroffen wurden.

Manche dieser Entscheidungen waren völlig vernünftig, als sie getroffen wurden. Andere waren Kompromisse. Und manche sind schwer zu ändern, weil inzwischen zu vieles von ihnen abhängt.

Das ist die Realität des Brownfield-Engineerings. Sie können nicht alles von Grund auf neu gestalten. Sie übernehmen ein System, verstehen seine Grenzen und finden einen Weg, es weiterzuentwickeln, ohne zu zerstören, was bereits funktioniert.

Der Post-Quanten-Übergang ist dafür ein besonders interessantes Beispiel. Wir werden die kryptografische Infrastruktur der Welt nicht über Nacht ersetzen. Wir werden sie im laufenden Betrieb migrieren müssen. Manche Produkte werden sich leicht aktualisieren lassen.

Andere werden Änderungen an Firmware, Hardware, Fertigungsprozessen oder ganzen Vertrauensketten erfordern. Manche werden noch lange im Einsatz sein, nachdem ihre ursprünglichen Entwickler längst weitergezogen sind.

Und während dieses ganzen Prozesses müssen die Hersteller weiterhin Sicherheit, Verfügbarkeit und Compliance gewährleisten. Für mich ist das viel interessanter als die übliche Diskussion darüber, wann Quantencomputer leistungsfähig genug sein werden, um die heutige Kryptografie zu brechen.

Die eigentliche Ingenieursarbeit beginnt lange bevor es so weit ist.

Und sie findet in Systemen statt, die es bereits gibt.

CTO zu werden hieß nicht, das Design hinter mir zu lassen

Noch etwas möchte ich ansprechen, weil es damit zu tun hat, wie ich meine Rolle sehe.

Den größten Teil meines Berufslebens galt ich als Designer.

Product Designer. UX Designer. Design Lead.

Diese Titel haben sich im Lauf der Zeit geändert, aber im Kern ging es bei der Arbeit immer darum, Systeme zu verstehen, ihre Grenzen und die Menschen, die mit ihnen umgehen.

Ich habe Design nie als etwas betrachtet, das auf Oberflächen beschränkt ist.

Eine Oberfläche ist einfach der Teil eines Systems, der sichtbar wird.

Dahinter stehen Entscheidungen über Architektur, Information, Verhalten, Leistung, Zuverlässigkeit und darüber, wie verschiedene Komponenten zusammenwirken.

Ein gutes Erlebnis lässt sich nicht gestalten, ohne zumindest einige dieser Entscheidungen zu verstehen.

Und je komplexer das Produkt wird, desto weniger bringt es, Design und Engineering als völlig getrennte Disziplinen zu behandeln.

Der Wechsel in die CTO-Rolle bei Shorium hat an dieser Sichtweise nichts geändert.

Er hat sie erweitert.

Heute verbringe ich viel mehr Zeit damit, über Architektur, Technologieentscheidungen und Engineering-Prozesse nachzudenken und darüber, wie sich eine Plattform bauen lässt, die sich weiterentwickeln kann, ohne unnötige Komplexität anzuhäufen.

Leistung ist mir wichtig. Wartbarkeit ebenso. Und ebenso die Möglichkeit zu verstehen, warum sich ein System so verhält, wie es sich verhält.

Oberflächen liegen mir natürlich nach wie vor am Herzen.

Aber genauso interessiert mich, was passiert, bevor irgendetwas den Bildschirm erreicht.

Wie Daten erhoben werden.
Wie Beziehungen dargestellt werden.
Wie Systeme miteinander kommunizieren.
Wie Belege bewahrt werden.
Wie wir vermeiden, Abhängigkeiten zu schaffen, die später zu Problemen werden.
Und wie wir etwas bauen, das verständlich bleibt, während es wächst.

Für mich ist das keine Abkehr vom Design.

Ich sehe darin dieselbe Denkweise, angewendet auf einer anderen Ebene des Systems.

Vielleicht ist das für mich der interessanteste Teil dieses Übergangs.

Nach fünfundzwanzig Jahren arbeite ich immer noch an der Beziehung zwischen Mensch und Technologie.

Nur eben viel weiter unten im Stack.

Wie es weitergeht

Shorium steht noch am Anfang.

Wir bauen das Unternehmen in Turin auf, entwickeln die Plattform und arbeiten uns durch die wissenschaftlichen und technischen Herausforderungen, die dazugehören.

Es gibt Dinge, die wir wissen. Es gibt Dinge, die wir noch validieren müssen. Und es liegen reichlich schwierige Entscheidungen vor uns.

Mich interessiert es nicht besonders, Fähigkeiten anzukündigen, bevor es sie gibt, oder so zu tun, als wäre der Bau eines technisch ambitionierten Produkts eine einfache Sache.

Das ist es nicht.

Vor allem nicht an der Schnittstelle von Kryptografie, Embedded-Systemen, Softwarearchitektur und regulatorischen Anforderungen.

Aber ich glaube, dass es sich lohnt, das zugrunde liegende Problem zu lösen.

Jahrelang haben wir Sicherheit als etwas behandelt, das sich zu einem bestimmten Zeitpunkt beurteilen lässt.

Ein Produkt besteht ein Audit.
Ein Zertifikat ist gültig.
Ein Algorithmus gilt als sicher.
Ein Gerät erfüllt einen Standard.
Und dann vergeht die Zeit.
Das Produkt verändert sich.
Seine Abhängigkeiten verändern sich.
Die Welt um es herum verändert sich.

Die Frage ist, ob wir Systeme bauen können, die diese Veränderungen gut genug verstehen, um das Vertrauen über ihren gesamten Lebenszyklus hinweg zu erhalten.

Genau das versuchen wir bei Shorium.

Und deshalb habe ich beschlossen, den nächsten Abschnitt meiner Laufbahn dieser Arbeit zu widmen.

Ein Produkt kann noch lange weiterlaufen, nachdem sich die Annahmen geändert haben, die es vertrauenswürdig gemacht haben.

Ich finde, wir sollten wissen können, wann das passiert.

Am besten, bevor etwas kaputtgeht.

Shorium — Cybersecurity for Continuity

Ursprünglich erschienen auf Brownfield AI.