Hadmut Danisch
Ansichten eines Informatikers

Große Bedenken: Ist die Luca App faul?

Hadmut
31.3.2021 20:55
Uncategorized

Eine Luftnummer?

Ich hatte neulich schon mal die Luca-App erwähnt. Ich kann bisher nichts dazu sagen, weil ich die App schlicht nicht kenne.

Ich hatte aber schon einen Blogartikel angefangen (nicht veröffentlicht), weil mir die Art und Weise, wie da Smudo und in einer Sendung eben auch Ranga Yogeshwar für diese App trommelten, einfach verdächtig vorkommt. Von Ranga Yogeshwar kommt mir einfach alles verdächtig vor, und wenn Smudo einen erzählt, man müsse da nur düpp-düpp-düpp machen, dann stinkt das auch. Ich kann mich nicht erinnern, dass jemals irgendetwas an Software seriös war, bei dem an die Bedienung mit „Man macht einfach düpp-düpp-düpp” und klickt nur auf seinem Handy herum, irgendwie seriös war.

Vorgestern war der dann wieder da, in den Tagesthemen oder heute journal, wieder ging’s darum, wie gut seine App sei. Wieder bejubelt. Da sind mir Aussagen aufgefallen, die mir unlogisch erschienen. Das gehört ja zu meinem Beruf, zu erkennen, wenn mir einer was zu Softwareeigenschaften erzählt, was nicht logisch, nicht stimmig ist.

Die Daten seien sicher. Weil sie seien ja verschlüsselt.

Typische Snake-Oil-Argumentation. Denn Daten sind auch dann, wenn sie verschlüsselt sind, nicht sicherer als der Schlüssel. Und das ist mir nicht klar, wer den hat. Oder um das mal mit einer Danisch-Krypto-Herangehensweise (Diss) zu erläutern: Bevor man sich dem unbefugten Dritten anschaut, sollte man den Blick zuerst auf den befugten Zweiten wenden. (Oder für Insider: Wenn Bob schon ein Mistbock ist, braucht Alice keinen Angreifer mehr.) Angreiferposition.

Die Daten seien noch sicherer, weil sie seien ja sogar doppelt verschlüsselt.

Warum verschlüsselt jemand Daten doppelt? Traut er seiner eigenen Verschlüsselung nicht? Ich glaube, es war in „Spiel mir das Lied vom Tod”, wo sie einen erschossen, weil er an seinen Hosen Gürtel und Hosenträger trug. Sie könnten keinen gebrauchen, der seinen eigenen Hosenträgern nicht vertraut.

Und die persönlichen Daten würden das eigene Handy nie verlassen. Schön. Aber wozu gebe ich sie dann überhaupt ein? Ich weiß doch auch ohne Handy, wie ich heiße.

Und noch was: Wenn ich mich beim Wirt in eine Papierliste eintragen muss, dann sieht der, ob ich das getan habe. Woher aber sieht der, ob ich mit dem Handy einen QR-Code gescannt und aufgerufen habe?

Ich hatte dann nachts mal einen Blick auf deren „Dokumentation” geworfen. Auf ihrer Systembeschreibung heißt es:

Sicherheit und Kryptographie

  • Das Kryptokonzept hinter luca wird gemeinsam mit Prof. Dr. Marian Margraf von Fraunhofer AISEC entwickelt
  • Umsetzung und Entwicklung erfolgen durch neXenio (Ausgründung HPI, 60 Mitarbeiter), gemeinsam mit Partnern wie dem Hasso-Plattner-Institut und der Bundesdruckerei
  • Penetration Tests wurden mit ERNW durchgeführt​
  • Die Anbindung an die Gesundheitsämter und Support erfolgen beim landesweiten Rollout durch die Bundesdruckerei
  • Kontaktinformationen werden 2-fach verschlüsselt auf ISO-27001 zertifizierten, deutschen Servern gespeichert und nach maximal 30 Tagen gelöscht

Das überzeugt mich überhaupt nicht. Mal abgesehen davon, dass mir der Name „Prof. Dr. Marian Margraf” nichts sagt, sind meine Haltung und meine Lebenserfahrung, was das Thema Kryptographie und deutsche Professoren angeht, hinlänglich bekannt. Und ich habe eine massive Abneigung gegen Leute, die – wie Geisteswissenschaftler – etwas damit begründen, dass sie auf eine bestimmte Person verweisen, ohne aber Informationen zu geben. Man soll da einfach blind irgendeinem Professor vertrauen.

Auch das Hasso-Plattner-Institut zählt jedenfalls bei mir nicht zur Kategorie „positiv”. Denen traue ich nicht weit über den Weg. Und ich habe meine Gründe (die auch, aber nicht nur in meinem Promotionsverfahren liegen).

Penetration Tests durchgeführt zu haben sagt schon mal rein gar nichts, solange nicht dabei steht, was das Ergebnis der Tests war. Und selbst, wenn das Ergebnis sauber ist, sagt das nichts über die Abwesenheit von Löchern, weil Pentests nur deren Anwesenheit, aber nicht deren Abwesenheit zeigen können. Gerade dann, wenn man Server nicht für die Öffentlichkeit mit eigenen Clients, sondern nur für selbst produzierte Clients (Anwendungsprogramme, Apps usw.) anbietet, ist es relativ leicht, sie PenTest-dicht zu machen, und trotzdem jede Menge Löcher drin zu haben. Man muss nur ein Client-Zertifikat oder Passwort zur Anmeldung fest in die Applikation einbauen, und schon sieht der PenTest nichts mehr, auch wenn das Ding offen rumsteht.

Warum werden Kontaktinformationen 2-fach verschlüsselt auf Servern gespeichert? Was sagt das, wenn nicht dabei steht, wer die Schlüssel hat?

„auf ISO-27001 zertifizierten, deutschen Servern gespeichert”. Ja, nett. Hört sich an, als hätte man die so gebraucht gekauft, mit Zertifizierung. Wenn aber nur die Server zertifiziert sind, hilft das nicht viel. Wenn beispielsweise die Applikation selbst nicht sicher ist. Oder wenn der Betreiber nicht seriös ist. Generell hilft das mit den Zertifizierungen nicht viel, solange man die Details nicht gelesen hat. Wenn ich da reinschreibe, dass ich eine Gefahr für nicht relevant halte und deshalb nichts dagegen unternehme, kann ich dafür auch ein Zertifikat bekommen, weil der Auditor sieht, dass man sich um den entsprechenden Punkt im Katalog gekümmert hat.

Das ist alles so heiße Luft, nichts greifbares.

Also hatte ich mich zuerst gefreut, dass sie da ein Sicherheitskonzept haben. Ich habe da vorgestern, nachts um 2, mal reingesehen.

Ich habe nicht alles gelesen, aber überall da, wo ich gelesen habe, nur Gesülze und Geblubber gelesen, nichts Konkretes. Das liest sich wie von jemandem, der noch nie ein Sicherheitskonzept geschrieben hat. Überschriften und dazu Blabla.

Beispiel Actors:

Actors

Guest

A person that is required to securely provide their Contact Data to the Luca system before entering a venue and later (on infection) submit their location history (Check-In History) to the Health Department.

Technically the Guest can be in one of three roles: Uninfected Guest, Traced Guest or Infected Guest. Depending on their role, the security guarantees provided for the Guest change. For example, no component in the system other than the Guest App will ever learn an Uninfected Guest’s Contact Data. In contrast, the Contact Data of Traced Guests is made available to the Health Department.

Uninfected Guest

The default role of a Guest. Neither the Check-In History nor Contact Data has been shared with the Health Department.

Traced Guest

A Guest who is part of a Contact Tracing Process. This Guest’s Contact Data is revealed to the Health Department.

Infected Guest

A Guest who is suspected of being infected with Sars-CoV2 and has consented to sharing their Check-In History with the Health Department.

Das ist jetzt inhaltlich noch nicht so verdächtig, aber begrifflich. Denn der Begriff „role” ist hier völlig falsch verwendet. Das, was die da beschreiben, wäre Zustand, State. Eine Rolle ist im Kontext der IT-Sicherheit – Stichwort Role Based Access Control – eine Abstraktion von Zugriffsrechten im Bereich der Autorisation und eine Unterteilung der Zugriffsrechte eines Principals/Rechteinhabers. Beispiel: In einer Schule kann man definieren, welche Zugriffsrechte Lehrer oder der Direktor hat, und dies allgemein definieren, ohne die Rechte einzeln für Lehrer Lempel und Lehrer Specht einzutragen. Und wenn einer gleichzeitig Lehrer und Direktor ist, dann wechselt er zwischen den Rollen Lehrer und Direktor.

Das hier ist etwas völlig anderes. Es definiert nicht die Zugriffsrechte der „Gäste”, und die können auch nicht je nach Tätigkeit diese oder jene Rolle einnehmen.

Das ist zwar grundsätzlich kein Problem, einen anderen Begriff zu verwenden, dadurch wird das Ding ja noch nicht unsicher. Aber es zeigt schon, dass das Ding von jemandem geschrieben wurde, der mit Sicherheitskonzepten nicht so vertraut ist.

Trusted 3rd Party

A person or institution that is not affiliated with luca, its developers or operators. A trusted 3rd party is required to perform vital initialization steps regarding luca’s system setup. Note that different mentions of Trusted 3rd Party throughout the document can refer to different institutions

Wenn es eine Trusted 3rd Party braucht, wird man immer hellhörig. Es ist immer eine sehr interessante Frage, wem man denn da so „trusten” muss.

Mal ein Blick in die Sicherheitsziele:

O1. An Uninfected Guest’s Contact Data is known only to their Guest App

The Guest’s personal data is undisclosed as long as they didn’t test positive (and become an Infected Guest) or show up in a tracing process by a Health Department (and become a Traced Guest)

Das stinkt schon.

Denn a) woher weiß die App, ob man positiv gestestet wurde? Und b) Wieviel ist das wert dass die Daten in der App bleiben, solange man im Status „uninfected” ist, wenn man doch in einen Tracing Process versetzt wird?

O6. Traced Guest’s Contact Data is disclosed to the Health Department only after Venue Owners’ consent

This requirement is meant to mitigate illicit disclosure of arbitrary Guests’ contact information by the authorities.

Stinkt auch. Denn was ist, wenn der Kneipenwirt – aus welchen Gründen auch immer – seinen consent nicht gibt? Er hat ja keine Mitwirkungspflicht. Was ist, wenn der nicht an Corona glaubt oder um seinen Umsatz fürchtet?

Das wirft die nächste Frage auf: Damit es von seinem Consent abhängig ist, müsste der Wirt einen Schlüssel haben, den nur er besitzt. Das geht schief, weil viel zu viele Betreiber von Etablissements gar nicht in der Lage sind, einen Schlüssel zuverlässig aufzubewahren. Liegt der Schlüssel aber woanders, nämlich auf dem Server, geht’s eben auch ohne Consent des Wirts.

Das sind so Sachen, die einem beim Lesen auffallen, weil das Dinge sind, die so grundsätzlich nicht funktionieren. Das findet man immer wieder in Protokollen von Anfängern, Laien (oder geförderten Frauen, die damit dann mit Auszeichnung promovieren), dass „Sicherheitsprotokolle” nur funktionieren, solange jeder ehrlich mitspielt. Wenn aber jeder ehrlich mitspielt, braucht man kein Sicherheitsprotokoll. Sicherheitsprotokolle sind dafür da, wenn einer nicht ordentlich mitspielt. Ihr müsst Euch das vorstellen, wie einen Sicherheitsgurt im Auto. Die einen sind nur gut, solange man keinen Unfall baut. Dann bräuchte man sie aber gar nicht. Und nur die, die auch beim Unfall ihre Aufgabe erfüllen, sind tauglich.

Secrets:

daily keypair

The keypair whose public key is used by the Guest App to encrypt the secret part of the Check-In data. Its private key is used by a Health Department during the process of Contact Tracing.

The keypair’s public key is signed using the HDSKP and stored on the Luca Server. Its private key is encrypted for each registered Health Department’s HDEKP. The encrypted private keys are stored on the Luca Server.

The daily keypair’s life cycle and usage is detailed in the chapter Daily Keypair Rotation.

Aha. Wenn das Health Department den private key des daily keypair hat, was bringt es dann, täglich einen neuen zu erzeugen? Dann hat man nach 30 Tagen 30 Schlüsselpaare und das Health Department hat alle 30 private keys. Kann also trotzdem alle lesen.

Wozu soll das gut sein?

badge keypair

The keypair that encrypts contact data references for static Badges. The public key is used exclusively by a Trusted 3rd Party during the generation of static Badges. Its private key is owned by the Health Department and is used to decrypt Check-Ins created using a static Badge.

Ah. Keypair encrypts contact data references for static Badges. Und die werden von einer Trusted 3rd Party aufgesetzt. Bis hierhin hört es sich – bis auf ein böses Fehlerdetail – noch gut an. Aber dann: „Its private key is owned by the Health Department and is used to decrypt Check-Ins created using a static Badge.”

Moment mal.

Es gibt ein Schlüsselpaar, mit dem die Trusted Third Party die „static badges” erstellt. Das wäre im Prinzip nicht schlecht, aber stimmt was nicht. Denn nach dem Text hat die „Trusted 3rd Party” den „public key”. Während den private key das Health Department hat. Das ist bullshit. Denn dann ist sie ja nicht trusted, sondern der Schlüssel beim Health Department, und einen public key kan man nicht exclusively usen, denn er ist ja öffentlich (drum heißt er so), es kann ihn also jeder benutzen.

Was verstehen die unter „badges”? Im Security-Bereich kann man darunter gewissen Tokens verstehen, die einen Schlüssel in einem USB-Stick, Sender oder sowas verbergen, damit er geheim bleibt. Was aber verstehen die hier unter „badge”? Soll doch nur mit Handys arbeiten. Gucken wir nach:

Badge

A printable QR code in the form of small badge to allow people without a smartphone to check-in at luca locations.

Hä!?

Ein QR-Code soll ein Badge sein, den die Trusted 3rd Party mittels des public key, den nur sie benutzt, ausstellt.

So’n Quatsch. Einen QR-Code kann man beliebig kopieren. Auf’n Kopierer legen, Knopf drücken, fertig.

Und wie, bitteschön, sollen denn Leute ohne Smartphone einen QR-Code verwenden, um sich einzuchecken?

Etwas klarer wird das erst, wenn man sich das Diagramm anschaut. Der Gast soll wohl wahlweise über das Handy, ein Web-Frontend oder diesen QR-Code, den er mit sich herumträgt, einchecken.

Das ist prima, denn wenn der printable ist, dann holte sich den einer, stellt den ins Netz und verteilt ihn über Social Media, und schon ist jener Fritz Meier am selben Abend in allen Restaurants der Stadt gleichzeitig, weil 1000 Leute denselben QR-Code vorzeigen.

Nochmal zurück zu secrets:

data secret

A secret cryptographic seed which is used to derive both the data encryption key and the data authentication key. This seed is encrypted twice before being sent to the Luca Server during Check-In and ultimately protects the Guest’s Contact Data. It is stored locally in the Guest App.

Das würde mich mal interessieren, wie das gehen und was genau da ablaufen soll. Wenn wenn das Ding für die Erzeugung so wichtiger Schlüssel dient, muss man es schon geheim halten. Was genau heißt dann „encrypted twice”? Doppelt hält besser? Encrypted womit? Wer hat denn die Schlüssel dazu? Woher kommen die?

data encryption key

A symmetric key derived from the data secret, used to encrypt the Contact Data.

Stinkt.

Einen symmetrischen Schlüssel derived man nämlich üblicherweise und aus guten Gründen nicht. Sowas macht man mit symmetrischen Schlüsseln, auch weil es damit geht. Man kann aus irgendwas eine Bitfolge als geheimen symmetrischen Schlüssel erzeugen. Aber einen assymmetrischen Schlüssel aus etwas abzuleiten ist nicht so einfach. Zufallszahl und dann von dort aus die nächste Primzahl suchen, oder wie soll das gehen?

Und selbst, wenn es geht, ist es ein Widerspruch in sich. Denn wenn das symmetrische Schlüsselpaar aus einem „data secret” „derived” wird (und „derived” heißt, dass es wiederholbar ist, also auch jeder tun kann, der das data secret kennt), dann ist es nicht private, weil der Absender des „data secret” das auch kann. Man kann den Text aber auch so verstehen, dass das Handy nur den Public key verwendet, um die Benutzerdaten zu verschlüsseln. Das wäre zwar nicht unsicher, aber Sinn oder Funktion ergäbe es wohl auch nicht, weil man nämlich den public key nicht aus einem data secret, sondern nur aus dem privat key ableiten kann. Den muss der Inhaber dann eben mitteilen.

guest keypair

An asymmetric keypair created during the Guest Registration.

The keypair’s private key is used to sign the encrypted guest data and guest data transfer object. The public key is uploaded to the Luca Server.

Das erscheint mir jetzt mal plausibel. Das verstehe ich und kann es nachvollziehen. Fragen wir mal, was die „Guest Registration” ist.

Guest Registration

In this process a new Guest registers to the Luca system. This process is required for Guests using the Guest App. During this process, local secrets are created, the Guest enters their Contact Data and identifiers and encrypted data are sent to the Luca Server.

Aha. Hört sich an, als wäre ich heute Batman, morgen Spiderman und übermorgen Angela Merkel. Schauen wir uns mal das Protokolldiagramm an. Es wird eine TAN per SMS verschickt. Dann bin ich eben Batman mit meiner Mobilfunknummer. Oder Angela Merkel. Denn eine Prüfung, ob der Name zur Mobilfunknummer passt, kommt nicht vor. Und eine Abfrage beim Provider ist dafür telekommunikationsrechtlich nicht vorgesehen.

Schauen wir uns das Onboarding an: Keypair rotation

Daily Keypair Rotation

As Health Departments are federated in Germany, they need to share a common keypair (namely the daily keypair). This keypair is generated and distributed among all Health Departments on a daily basis. For the distribution, we use the HDEKPs (that are uniquely owned by each health department) to encrypt the daily keypair’s private key for each Health Department. These encrypted private key objects are then uploaded to luca

Ich habe immer noch nicht verstanden, wozu diese daily rotation gut sein soll.

Die machen jeden Tag ein neues Schlüsselpaar – und verteilen dann das Schlüsselpaar (auch den private key) an alle Gesundheitsämter?

Ein private key, den die alle haben?

Auch das stinkt. Das geht doch schief. Deshalb jeden Tag einen neuen? Weil die so schnell versickern?

Checkin

Generation of Static Badges

A static Badge is a small key fob with a QR code printed on one side and a badge serial number on the flip side. It provides an alternative to the smartphone based Check-In for less tech-savvy Guests. The QR code for Badges are generated by a Trusted 3rd Party and manufactured in bulk by a print shop. Prior to the first Check-In Guests must personalize their Badge with their Contact Data using the Badge Personalization Frontend. […]

The Badge Generator software creates each Badge by randomly choosing a 56-bit serial number. All cryptographic assets and the associated user ID for the generated Badge are then derived from this initial seed (aka. the badge serial number). The newly generated Badge is then registered with the Luca Server via an authenticated API request 1. In response, the Luca Server creates a remote attestation signature for the badge using its badge attestation keypair. Eventually, the relevant information is encoded into a QR code and printed on a plastic key fob along with the initially generated serial number.

The Badge Generator runs the following algorithm to generate a Badge: [Die bringen tatsächlich Programmcode, um eine Zufallszahl zu signieren und auszudrucken.]

Schön.

Der übliche Fehler.

Denn das läuft, wenn alles läuft und jeder mitspielt. Security ist aber, wenn mindestens einer nicht mehr mitspielt.

  • Was ist also, wenn der Gast einfach irgendeinen QR-Code selbst druckt? Dann spuckt das Ding eine Fehlermeldung aus, dass es den Code nicht kennt. Und dann? Der Gast sagt, er habe sich registriert. Der Luca-Server spinne. Nicht sein Problem. Muss der Wirt also bei der Anmeldung zuschauen und prüfen, dass der Server zufrieden ist?
  • Woher weiß umgekehrt der Gast, dass der Wirt einen echten Scanner aufstellt und nicht etwa ein Fake-Gerät?

Tracing:

Der infizierte Gast muss selbständig und gewollt den Prozess initiieren. Was ich mindestens 70% der Berliner Bevölkerung wirklich nicht zutraue.

Dann gibt es ein kompliziertes Protokoll mit übertragung einer TAN an einen Behördenmitarbeiter (da muss ein Mensch mitspielen), anstatt einfach im Handy die Freigabe zu erlauben. Da wird Kommunikations- mit Systemsicherheit verwechselt.

Und dann soll da im zweiten Teil irgendwie der betroffene Gast auch noch zustimmen. Sieht nach viel Handarbeit aus.

Kommentar

Ich will daraus jetzt nicht schlussfolgern, dass da irgendwas unsicher ist. Zumal ich die Beschreibung auch nur stellenweise überflogen und nicht vollständig gelesen habe.

Aber: Diese Beschreibung überzeugt mich nicht.

Das ist von jemandem mit Halbwissen mit der heißen Nadel zusammenstrickt, der schon mal irgendwo gesehen hat, wie sowas aussieht, und dann das übliche Geschreibsel immitiert.

Das heißt nicht, dass der Code und das Protokoll selbst schlecht sind, aber zumindest in der Beschreibung stimmen manche Begriffe nicht, und es fällt mir vor allem auf, dass wer das Konzept geschrieben hat, zwischen Konzept, Protokoll und Implementierung nicht unterscheiden kann. Es werden Implementierungsdetails als Konzept ausgegeben, sie sollen aber dem Konzept folgen und es nicht erzeugen.

Ich kann das nicht abschließend beurteilen, weil das nach diesem Text – den ich nicht mal ganz gelesen habe – nicht zu beurteilen ist. Das sind zuviele Faselformulierungen wie „derived” und irgendein Secret wird benutzt um zu [irgendwas].

Am schlimmsten finde ich, dass etwas als Sicherheitskonzept ausgegeben wird, was kein Sicherheitskonzept ist. Es wird nur beschrieben, dass alle mitmachen müssen und wie es läuft, wenn alle mitmachen. Der klassische Anfängerfehler, sieht man an den Universitäten ständig, ein Sicherheitsprotokoll damit zu beschreiben, dass alle schön mitmachen, dass es also funktioniert, wenn keiner angreift und jeder mitspielt. Dann brauche ich aber kein Sicherheitsprotokoll und -konzept. Sicherheitsprotokolle und -konzepte braucht man, wenn der Böse kommt und mitmacht, sich aber nicht an die Regeln hält.

Und sowas kommt darin überhaupt nicht vor.

So ein typischer Unterschied, die typische Diskrepanz zwischen akademischem Gesülze, wie man es Hochschulprofessoren als Diplomarbeit oder Dissertation andrehen kann, und der Realität der IT-Sicherheit. Als ob man ein Gefängnis baut, das nur hält, solange keiner versucht, auszubrechen. Oder einen Flughafen, von dem keiner abfliegen will.

Ich glaube das gerne, dass die da einen Professor gefunden haben, der ihnen seinen Namen draufdrückt. Gibt ja auch Genderprofessoren. Man findet für alles, wirklich alles einen Professor.

Anlass

Manch einer wird jetzt fragen, warum der Danisch das jetzt schreibt, wenn er das noch nicht ganz gelesen hat. Warum er damit wartet, bis er es gelesen hat. Wollte ich eigentlich. Deshalb hatte ich den Artikel eigentlich auch vor 2 Tagen nach der Tagesthemen- oder heute-journal-Sendung schon angefangen, in der Smudo auftrat.

Eben kam aber das:

Die scheinen da die Lizenzen nicht beachtet zu haben.

Anscheinend ist das wirklich auf die Schnelle irgendwie zusammengerührt worden.

Versteht mich nicht falsch: Es kann unter Krisenbedingungen besser sein, eine lückenhafte oder schlecht beschriebene App zu verwenden als gar keine. Selbst wenn die jede Menge Lücken hätte, wäre das noch nicht zwingend schlechter, als gar nichts zu tun. Auch Impfungen haben ein Risiko, das aber geringer sein kann als wenn man nichts tut.

Gerade weil aber die Rede davon war, dass die im Hintergrund schon Verträge mit den Ministerien abschließen, und sich ein Mietmaul wie Ranga Yogeshwar hinsetzen – und von dem ist ja bekannt, dass man sich seine Fürsprache mieten kann, würde mich also interessieren, ob das ein bezahlter Auftritt war – ob da nicht welche eine ganz krumme Geschäftemacherei abziehen wollen.

Ich habe schon zu Anfang gesagt, dass ich es für naiv halte, zu glauben, dass man eine Pandemie mit einer – düpp-düpp-düpp – Handy-App lösen kann.

Ich gewinne langsam den Eindruck, dass da auch welche das große Geld machen wollen.

Diese Dokumentation macht auf mich nicht den Eindruck, als ob die sich so wirklich damit auskennen. Das wirkt irgendwie zusammengerührt.