Posts Tagged ‘Zertifikat’

Sonntag, 2. Januar 2022

Augenzeugenbericht aus dem Omikron-Bergamo New York City

Der Familienausflug nach New York City (NYC) neigt sich rasch dem Ende zu — ich sitze mit Stephanie gerade in der Lounge am Flughafen Newark im nahgelegenen New Jersey und warte darauf, dass wir LX19 zurück in die Schweiz besteigen können.

Wir sind am Montag-Abend von San Francisco kommend in Newark gelandet. Ungefähr ein, zwei Tage später trafen über WhatsApp und Co. die ersten besorgten Nachrichten von Verwandten und Bekannten aus der Schweiz ein. Sie verlinkten Artikel in der einschlägigen Schweizer Qualitätspresse, die von rasant steigenden positiven Testzahlen aus Big Apple sprachen.

Vom „Bergamo am Hudson“ oder der „Omikron-Hölle“ sprach glaub ich kein Journalist, aber die Nachrichten tönten wie gewohnt alarmistisch. „Journalismus“ à la 2021 halt.

Unsortierte Beobachtungen:

  • Alles halb so wild: Vom angeblichen Ausnahmezustand merkt man nichts. Keine Leichenberge an den Strassenrändern, niemand kippt gelegentlich vor den eigenen Augen um. Es ist wie immer laut (Lüftungen, aber auch wegen des Verkehrs und der wie gewohnt häufig eingesetzten Hupen), es stinkt, und es gibt grosse Menschenmassen. Würden die Leute keine Masken tragen, und würden die Impfbüchlein nicht geprüft, würde sich meiner Meinung nach alles ganz normal anfühlen.
    • Am Surrealsten war ein Pub-Besuch am ersten Abend zwecks Bier: Keine Impfausweiskontrolle, der Laden bumsvoll, stickige Luft — und als Neil Diamonds „Sweet Caroline“ anläuft singen alle lauthals mit. Leute mit panischer Angst vor Corona hätten das Lokal vermutlich nur noch mit PTSD/PTBS verlassen.
  • Flächendeckend 1G: In der Theorie müssen alle Lokale (Hotels, Restaurants, Museen, Botanischer Garten …) den Impfausweis kontrollieren. In Praxis wurde das je nach Lokal unterschiedlich gehandhabt; einige ignorierten diese Vorgabe komplett, andere waren extrem pedantisch. Die High End-Lokale waren meiner Erfahrung nach strikter als Pubs und dergleichen.
  • Kein digitaler Impfpass sie alle zu knechten: Amerika kennt keine digitalen Impfausweise. Jeder geimpfte Amerikaner hat eine graue Impfkarte, auf welcher die Daten der Impfung eingetragen sind. Fälschungssicher? Denkste. Viele Leute haben den Impfausweis „digitalisiert“, indem sie das Papier abgeföttelet haben und ihn nun mit dem Smartphone überall hin mitnehmen. Wird problemlos akzeptiert. Hier hat man halt ein anderes Verständnis von gelebter „Compliance“ (beidseitig; auf Seite der Restaurantkunden, aber auch auf Seiten der Restaurantbetreiber). Gefällt mir. Schlussendlich muss das der Staat kontrollieren und forcieren, wenn er das unbedingt so will, und nicht die Restaurateure als Handlanger.
  • Ausländische QR-Code-basierte Impfpässe: Ich habe jedes Mal das Zertifikat meiner Covid-App gezeigt (das gelbe WHO-Impfbüchlein lag im Pass im Hotel im Safe). In den meisten Fällen wurde die Übung abgebrochen, als die Restaurateure oder Türsteher etwas von „Moderna“ in der App lasen. Das Datum der letzten Impfung spielte keine Rolle. Der Name auf dem Zertifikat wurde selten mit der Photo ID (meiner Schweizerischen Identitätskarte, oder dem Schweizerischen Führerschein) abgeglichen. Ob das Gesicht mit der ID übereinstimmte interessierte ebenfalls niemanden. Hauptsache man hatte auf dem Handy einen bekannten Impfstoff aufgeführt, und etwas dabei, das wie ein Ausweis in Kreditkartenform aussah.
    • Am 30. Dezember dann die Überraschung: Fred, das Unikat von Türsteher beim Comedy Cellar kannte Europäische QR-Codes, zückte sein Android-Smartphone, öffnete eine App und validierte den QR-Code. Das erste und letzte Mal, das mir dies hier widerfuhr.
  • Unzählige Maskenträger im Freien: Ich konnte es nicht glauben, wie viele Leute an der frischen Luft mit Masken herumliefen.
  • Maskentypen: Bedruckte Community-Masken, wie ich sie trage, sieht man nirgends. Gelegentlich löste meine Masken längeres Starren aus — ich denke, die Leute wunderten sich, was genau aufgedruckt ist.
  • All you can test: Über die Innenstadt gibt es überall Testzelte verteilt. Die Schlangen davor sind sehr lange — denn jede Person kann sich gegen vorzeigen eines Identitätsdokuments testen lassen. Es wird keine Krankenversicherung, Kreditkarte oder Bargeld benötigt. Sprich: Kostenlos. Sprich: So oft wie man will. Sprich: Ein Paradies für die Hypochonder und Angstneurotiker.
    • Leider vergass ich bei unserem Testtermin zu fragen, wie viel Prämie die Arztpraxen pro Test erhalten. Ich glaube aber, dass sich das Geschäft sehr gut rentiert, sonst hätte uns die Arztpraxis abgewiesen.
  • Überlastete Labors: Bei einem Zelt lasen wir, dass die Testresultate nach drei bis fünf Tagen nach dem Test eintreffen — im vollen Bewusstsein, dass die Isolationsdauer bei einem positiven Test kürzlich von zehn auf fünf Tage reduziert wurde. Die Labors seien überall am Anschlag. Eigentlich wollten wir uns am Morgen des 31. Dezembers testen lassen, entschieden uns dann aber, den Test bereits am Nachmittag des Vortages durchzuführen. Zum Glück: Das Testresultat meiner Frau traf heute Nacht um 2 Uhr morgens ein, meines um 6 Uhr morgens. Wären wir wie geplant erst am Freitag testen gegangen, hätte es für den Check-In am Flughafen höchstwahrscheinlich nicht gereicht. Leider wird der CT-Wert auf dem Testresultat nicht angezeigt.
  • Testzenter unseres Vertrauens: Wir haben uns bei Urgentway in Manhattan testen lassen (die Adresse hatte meine Frau irgendwo im Netz ausgegraben). Es handelt sich um eine Arztpraxis im sechsten Stock des Gebäudes an der 535 8th Ave in NY 10018. Für Tests reiht man sich in die Schlange vor dem Gebäude ein. Die Schlange wächst dabei mehr und mehr, und gelegentlich (ca. alle 20-30 Minuten) kommt ein Angestellter runter und holte sechs bis acht Personen hoch in die Praxis. Dort weist man sich aus und es wird ein Patientedossier angelegt. Anschliessend geht es nach und nach einzeln in ein Abstellkämmerchen zum Test. Freundlicherweise bohrt einem die Ärztin (oder: MPA?) das Stäbchen nur in ein Nasenloch, und stösst es auch nicht bis ins Hirn. Ich vermute, dass die Chance auf einen positiven Test so noch etwas geringer sind. Der ganze Spass hat uns ungefähr eineinhalb Stunden gekostet. Wichtig: Unbedingt unterschiedliche Email-Adressen angeben, da die Resultate in einem geschützten, personalisierten Bereich zur Verfügung gestellt werden. Das System hat Probleme, wenn zwei Personen dieselbe Email-Adresse hinterlegt haben. Vielleicht sollte das mal jemanden CureMD sagen?
  • Qualität der Restaurations-Services: Die USA setzen auf Grund der Gehaltsstruktur im Restaurationsbetrieb bereits in nicht-pandemischen Zeiten die höchsten Massstäbe. Dieses Mal empfand ich die Qualität noch ein Mü besser und aufmerksamer — ich führe das auf die Umsatzeinbussen während der Lockdowns zurück. Unser Hotel war gefühlt nur zur Hälfte ausgebucht. Die Silvester-Sängerin, welche seit dutzenden Jahren im Hotel auftritt, erwähnte auch, dass der Esssaal in normalen Jahren bis zum Bersten gefüllt sei, man in diesem Jahr aber erstmals Freiräume zwischen den Tischen habe.

Fazit: Die Erfahrungen in New York (und: Kalifornien) haben mich beruhigt — wenn die Amis das mit dem QR-Code bis jetzt nicht gebacken gekriegt haben, werden sie es auch in Zukunft nicht. Und somit erachte ich den weltweiten Rollout des „Zertifikats sie alle zu knechten“ als höchst unwahrscheinlich. Hingegen ist in Europa der Zug zum „Rückbau“ des Zertifikats aber vermutlich längst abgefahren. Leider.

Und schliesslich wurde uns heute Nachmittag noch die Werbung für die „BIaZ“ — Beste Impfung aller Zeiten — von den Leuten an der Goldgrube ins Gesicht projiziert:

Meine Pfizer-Aktien freuts ungemein. Unbedingt weiterboostern!

Tags: , , , , , , , , , , ,
Labels: Gesundheit

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 28. Oktober 2021

Adolf Hitlers Covid-Zertifikat ist nicht „gefälscht“ …

Update: Das Covid-Zertifikat wurde revoziert, siehe Abschnitt „Nachtrag“.

… weil es mit einem offiziellen anerkannten Signing Certificate signiert wurde und deshalb von allen europäischen Check-Apps (in der Schweiz bspw. die iOS App Covid Check) als echt eingestuft wird.

Richtigerweise müsste man sagen: „Es sind echte Zertifikate mit unplausiblen Angaben im Umlauf“.

Via eines Artikels des Redaktionsnetzwerkes Deutschland: Fake-Impfzertifikat für „Adolf Hitler“ wird von offiziellen Apps akzeptiert

Zwischenbemerkung: Ich bin kein Public-key Kryptographiehirsch und es kann daher durchaus sein, dass ich mit meinem Halbwissen hier falsche Begriffe verwende und die Mechanismen fehlerhaft wiedergebe. Man möge mich darauf hinweisen, mir verzeihen und mich nicht wie Kimmich auf dem Scheiterhaufen der Narrativfrevler verbrennen.

Hier der QR-Code zum selber abföttelen (und zwecks Extraktion zusätzlicher Informationen, die in der Check App nicht angezeigt werden):

Offenbar sind weitere solche Zertifikate im Umlauf, wie eine Diskussion auf GitHub zeigt. Unter anderem eines ausgestellt auf den Herrn Mickey Mouse.

Auf Grund der offensichtlich unplausiblen Namen auf den Zertifikaten kann man im Ausschlussverfahren bereits einige Feststellungen machen:

  • Dem Ersteller war es egal, aufzufallen. Sonst hätten sie nicht Zertifikate auf Namen von toten Diktatoren und von Comicfiguren ausgestellt.
  • Und da sie aufgefallen/aufgeflogen sind, ging es ihnen offenbar auch nicht darum, mit dem „Hack“ Geld zu verdienen, noch die sich der Impfung verweigernden Mitglieder ihrer Grossfamilie und sonstige Bekannte still und leise mit gültigen Zertifikaten zu versorgen.
  • Stattdessen — und das ist aus meiner Sicht das wahrscheinlichste Szenario — ging es dem Ersteller darum, das Zertifikatssystem blosszustellen und zu diskreditieren.
  • (Oder aber diese auffälligen Zertifikate wurden erst erstellt, nachdem der Ersteller aufgeflogen waren und sie sich sagten: „Jetzt ist eh alles aus, dann machen wir noch ein, zwei Zertifikate für Ruhm und Ehre in den Hackerkreisen, um allen zu zeigen dass wir es geschafft haben und beliebige Zertifikate ausstellen konnten“)

Was bedeutet das nun konkret für das Zertifikat-Ökosystem?

  • Ein (oder mehrere!) Private Keys hinter den Signing Certificates sind in die falschen Hände gelangt. Dies würde bedeuten, dass alle von der betroffenen Certificate Authority ausgegebenen Zertifikate storniert und erneut generiert werden müssten — nachdem man ein neues Signing Certificate erstellt hat. Chaos vorprogrammiert, und insbesondere der Reputationsschaden.
    • Ich hoffe aber, dass die Private Keys entsprechend der Industry Good Practices geschützt in einem HSM abgelegt sind. Und wirklich nur dort.
    • Auch erachte ich es als unwahrscheinlich, dass der Private Key mit Brute Force berechnet wurde.
  • Ein (oder mehrere!) Insider mit Zugang zu den Systemen zur Ausstellung haben aus Jux solche Zertifikate generiert. In diesem Fall wird es relativ einfach sein, an Hand der Logs der offiziellen Systeme die fehlbaren Personen ausfinding zu machen (wäre der Private Key geleakt könnte man die Zertifikate auf irgendeinem System ausstellen). Ausserdem müssten die personenspezifischen Zertifikate revoziert werden, sofern das System darauf ausgelegt ist. Selbst wenn sie erfolgreich revoziert sind, müssten die Check Apps beim Scannen eines Zertifikats diese dann auch noch gegen die Revozierungsliste prüfen. Ob die Apps das wirklich machen, und wie das genau geht (in Echtzeit? oder mittels einer Denylist, die periodisch heruntergeladen wird, wenn das Smartphone einen Internetzugang hat), weiss ich nicht.
  • Verwandt: Unauthorisierte Angreifer sind eines oder mehrere Ausstellungssysteme eingedrungen, und zeigen uns und der Welt, dass sie mit ihrem Angriff erfolgreich waren.
  • Verwandt: Es handelt sich um Zertifikate, die Entwickler aus Testgründen erstellt haben. Entweder haben sie diese dann selber willentlich verbreitet, oder die Zertifikate wurden von deren Systemen gestohlen.

Sind wir gespannt, was nun passiert. Ich hole mir schon einmal eine Tüte Popcorn hervor … das wird lustig.

Nachtrag

Gestern (28. Oktober 2021) mit der Covid Check-Applikation:

Heute (29. Oktober 2021) mit der Covid Check-Applikation:

Erkenntnis: Die Covid Check-Applikation hat die Möglichkeit, revozierte Zertifikate zu erkennen.

Nachtrag 2

Mich nahm es Wunder, wie die Liste der revozierten Zertifikate in die Covid Check-App kommt.

Leider schaffte ich es in der Eile nicht, mich mittels mitmproxy noch mittels Proxyman zwischen die Kommunikation der App mit den Servern zu hängen.

Immerhin fand ich in den DNS-Logs beim Prüfen des Adolf-Zertifikats folgende Einträge:

29-Oct-2021 23:08:00.511 queries: info: client @0x7f02940a72b8 10.1.2.3#62957 (www.cc.bit.admin.ch): query: www.cc.bit.admin.ch IN TYPE65 + (10.1.2.53)
29-Oct-2021 23:08:00.511 queries: info: client @0x7f0294075c88 10.1.2.3#50648 (www.cc.bit.admin.ch): query: www.cc.bit.admin.ch IN A + (10.1.2.53)
29-Oct-2021 23:08:00.559 queries: info: client @0x7f029c0812c8 10.1.2.3#61548 (d1m3nqpmh6pah2.cloudfront.net): query: d1m3nqpmh6pah2.cloudfront.net IN TYPE65 + (10.1.2.53)

Damit ausgerüstet entdeckte ich das GitHub-Script verify_ehc.py:

...
# Switzerland:
# See: https://github.com/cn-uofbasel/ch-dcc-keys
ROOT_CERT_URL_CH = 'https://www.bit.admin.ch/dam/bit/en/dokumente/pki/scanning_center/swiss_governmentrootcaii.crt.download.crt/swiss_governmentrootcaii.crt'
CERTS_URL_CH     = 'https://www.cc.bit.admin.ch/trust/v1/keys/list'
UPDATE_URL_CH    = 'https://www.cc.bit.admin.ch/trust/v1/keys/updates?certFormat=ANDROID'
...

Ein Aufruf dieser URLs produziert folgende Fehlermeldung:

Whitelabel Error Page

This application has no explicit mapping for /error, so you are seeing this as a fallback.

Sun Oct 31 12:32:59 CET 2021
There was an unexpected error (type=Forbidden, status=403).

Auf der ebenfalls erwähnten GitHub-Seite github.com/cn-uofbasel/ch-dcc-keys liest man dann:

The BIT (Bundesamt für Informatik und Telekommunikation) has two REST endpoints at https://www.cc.bit.admin.ch/trust/v1 where (a) a list of DCC key parameters, and (b) a table of active key IDs can be fetched. Both calls seem to need a bearer token which we extracted from the BIT’s Android CovidCertificate app. As of July 15, 2021, the token is:

Authorization: Bearer 0795dc8b-d8d0-4313-abf2-510b12d50939

Although we don’t make use of the SDK (and therefore are not bound by the following) and believe that access to governmental public keys should be permissionless, we point to the comment in the Android app’s source code:

// If you intend to integrate the CovidCertificate-SDK into your app,
// please get in touch with BIT/BAG to get a token assigned.

See https://github.com/admin-ch/CovidCertificate-SDK-Android/ from where we grabbed the bearer token value from the gradle file.

Dann versuchen wir das mal:

$ curl --header "Authorization: Bearer 0795dc8b-d8d0-4313-abf2-510b12d50939" https://www.cc.bit.admin.ch/trust/v1/keys/list
{
  "activeKeyIds": [
    "e/YRqyv++qY=",
    "jYpr5GHCDiQ=",
    "JkFekJel6/o=",
    "/IcqIBnnZzc=",
    "02vdAOY/+gI=",
    "0L7AaIwu+EY=",
    "0kAwFy+vLpg=",
    "1+da8dKEjlE=",
    "25QCxBrBJvA=",
    "2BGoyFIyYPs=",
    "2JelGO/ymxQ=",
    "3IsdmTYkAAM=",
    "3LCRmucB9kU=",
    "3jqajzfHpKE=",
    "3lTmAZX19GQ=",
    "3lrBUHc4iQE=",
    "3oYtiEZ9wp4=",
    "4GkJs9YsYS4=",
    "4Qmniw7B0gc=",
    "5xtSr6KkAGA=",
    "6CDB1hL+uKU=",
    "6FNkACSMLEc=",
    "6VdOPLF8/Fg=",
    "6ag2wJkSHtk=",
    "7AfAwcpWOv0=",
    "7XLhQx1KXdQ=",
    "7rZbUrXNlLk=",
    "7z8+6oww2a8=",
    "8AnF/hcilSo=",
    "90CNG8dcdn0=",
    "9IZVOkJRZPQ=",
    "9v3FozjKAUo=",
    "AN1EeLIMAmo=",
    "AQCGDydsS1Q=",
    "ARrNkCRtprY=",
    "BEnvMVnNFK8=",
    "BKBFhNFXWAU=",
    "CvktK3hdjeY=",
    "CvmI4xOoMj4=",
    "DusseXrzqO8=",
    "Er5OTMwLd78=",
    "EzYR1uk/E0I=",
    "FDNJjaSCWi0=",
    "G3jDFQ1oK0Q=",
    "GMFMBu1RlCg=",
    "GuQPQRxbMsU=",
    "GvVR3e6VJIM=",
    "HeWuzGwEM5c=",
    "HhkeqvrtQ0U=",
    "IZftFLRmKGY=",
    "IaGR283U1jA=",
    "Is2JtrOJhik=",
    "JHd4CkNzadI=",
    "Jjql9rBrjHI=",
    "KG9lzdohSY0=",
    "L7XIA2gi2ps=",
    "M8bcnysCMj4=",
    "MrT00mhDxLQ=",
    "MtI93IMknMk=",
    "MxhfdcoHinc=",
    "NAyCKly+hCg=",
    "NCc6YSsVioM=",
    "NCdyt3s+cak=",
    "NJpCsMLQco4=",
    "ODqaG8mnbro=",
    "OKpEjMo/2MY=",
    "PBpDVqnJ7Us=",
    "Pbydc1LscXo=",
    "QacbC7DdD4U=",
    "R7q7yd90ZPU=",
    "TGjTR+Re+yk=",
    "TpQIkAHAym4=",
    "UZ1cSMaPcaQ=",
    "Uj77p+qIQNs=",
    "XkVWZqUeeFc=",
    "XuCERkHu8kY=",
    "YRYidQ+wetg=",
    "YU9+X9nepqU=",
    "YVpBYnLh1Hs=",
    "Yr8a8Rd+zqI=",
    "Z7k1XpIWZOE=",
    "ZDoFfkn+yhY=",
    "ZcfkloEvfGQ=",
    "bBnmkeVMV6A=",
    "bKmas9wa5tc=",
    "bfoj2trt6bE=",
    "c1XrnEBoj/c=",
    "ccgQ13tmkU8=",
    "cdm9Ymfwn2I=",
    "dhSzPDr4G2M=",
    "e+bFdywyJQE=",
    "e4lH6I4iMIM=",
    "e9SH8dtWwdY=",
    "eNNsg2jd4wA=",
    "eQOY6BDp+vM=",
    "f+4yAPIGTWg=",
    "f6J92LRKpj0=",
    "fGLuvg6n5wk=",
    "fNf883wPIEg=",
    "hA1+pwEOxCI=",
    "hFpY/ySOrwI=",
    "hgpHHrTb4ws=",
    "i5SVuCsR5TA=",
    "izUDZjGtHWY=",
    "juskqrNQf6k=",
    "kjEx2H7huNE=",
    "ln8K+9SqfuA=",
    "lrxgMs2Duac=",
    "lshLbYfCWRg=",
    "nHmZ5K96UY4=",
    "nPKEYm3gXzU=",
    "nTrG8glLUls=",
    "npo0ZWgdQSY=",
    "pSEfhlMubh4=",
    "qFNF2dC+mjQ=",
    "r9YkEJZgi9k=",
    "rKMDA66RiLE=",
    "rXP9L7xddL8=",
    "sYXcYixrOGA=",
    "tCM87WnaaQE=",
    "ub6Qmv9xtAo=",
    "vjm0I2ATJ+Y=",
    "vq08l/LTxhk=",
    "vvYa1vaWkGg=",
    "wb/2450PPrc=",
    "wtYpyAmNmdk=",
    "x3ch4ml934I=",
    "yWCRdph8XJs=",
    "7GBun0USD5E=",
    "IMgNr10pfPQ=",
    "YDAy+yvD5lU=",
    "r9RtWK9x7dM=",
    "crm1HLAeaTo=",
    "2Bh+2HrOg0c=",
    "lzGYCpOBQsU=",
    "ryvXsisPPeU=",
    "0JzyumjttZU=",
    "H6b6bQ8qij4=",
    "T8kbYovQlYU=",
    "4Ss2raOqhTw=",
    "JsReuAsmza8=",
    "ypEjzbYNqEw=",
    "2Yv0kajsIlA=",
    "mo/w8S8rZ0Q=",
    "FhciF/j3plg=",
    "gEIK4Q/lAG0=",
    "Amn7EaBy1ag=",
    "M+R7JFFk6G8=",
    "MJuQDybecd4=",
    "o11W81MgYYg=",
    "AX/m4PDDCXE=",
    "pe6raiG2dWE=",
    "rLMiGt6uB3U=",
    "eUVY16rD2Kc=",
    "hHffSLS1AIU=",
    "fNstNUxgGSI=",
    "l8W4rhh9nTs=",
    "ZpnsokK1DgM=",
    "Ui7DXQikstE=",
    "26Fcjnjuf2s=",
    "72XVTQ2A9Jw=",
    "7byt9scureM=",
    "EDSWY8Hnul4=",
    "IKMstf8yj/4=",
    "hWoyHrtJs+E=",
    "cS/wou0g/po=",
    "Xo78qgBEx8k=",
    "mqWkXpNR0Rk=",
    "FtUwA9uHJoo=",
    "Pcl7yBWEQ7c=",
    "Cj0KwOpRFvQ=",
    "53FOjX/4aJs=",
    "ohI9KlFR2P8=",
    "rVPuf3yKLBg=",
    "l+UqotarLJc=",
    "hGUS4Zj9fLM=",
    "2eCjZcuOoEo=",
    "d+WbDD8Gr5g=",
    "TQeqi04M2ek=",
    "JZhMLV9Gyck=",
    "oVKwwScGxuY=",
    "Ll3NP03zOxY=",
    "rTEJEs6D1ik=",
    "1MTFjluEWHU=",
    "KBPNEuXUvrY=",
    "1PtilTAMiyk=",
    "I0+qkOLr2e0=",
    "jeetFC69E6o=",
    "lYkujLws7SE=",
    "osFRFyFIWdU=",
    "W0NjksmJMm0=",
    "26YSc5g0nG8=",
    "1J9pb87ndV0="
  ],
  "validDuration": 172800000
}

Hierbei handelt es sich vermutlich um die Liste der derzeit anerkannten Signing Certificates aller Herren Länder. 1J9pb87ndV0= scheint bspw. von Grossbritannien in Belfast (Nordirland) verwendet zu werden, während 2eCjZcuOoEo= (Zufallstreffer, i schwöre!) ein Schweizerisches Signing Certificate zu sein schein (Quelle).

Dasselbe klappt auch mit der Update API, welche offenbar auch die oben aufgeführten Keys enthält, aber noch mit mehr Informationen ausgeschmückt sind (ich zähle heute, am 31. Oktober 2021, für beide Listen je 193 Einträge; die zweite URL liefert 193 Zeilen mit „keyID“, die erste Liste enthält ebenfalls 193 Keys):

$ curl --header "Authorization: Bearer 0795dc8b-d8d0-4313-abf2-510b12d50939" https://www.cc.bit.admin.ch/trust/v1/keys/updates?certFormat=ANDROID
{
  "certs": [
    {
      "keyId": "e/YRqyv++qY=",
      "use": "sig",
      "alg": "ES256",
      "n": null,
      "e": null,
      "subjectPublicKeyInfo": null,
      "crv": "P-256",
      "x": "mCCGUDO95y6Rj40KX74cFgc99I9BnFoPBkZ3kcAyo2o=",
      "y": "v7JjeIG2FpKwtljBK7DfM2d+wvUYQBpR2AzfLTyW4gM="
    },
    {
      "keyId": "jYpr5GHCDiQ=",
      "use": "sig",
      "alg": "ES256",
      "n": null,
      "e": null,
      "subjectPublicKeyInfo": null,
      "crv": "P-256",
      "x": "lHOTKQPe3GZKCAIsaBbPpAfJZ30ftIUsb/r6gHu19cI=",
      "y": "NtVzH4mQ0LiN8HvNns7Jsoy/4369c5UWKly5m6jq5CQ="
    },
    {
      "keyId": "JkFekJel6/o=",
      "use": "sig",
      "alg": "ES256",
...

Ist das Adolf-Zertifikat vielleicht hier aufgeführt? Dazu verwende ich vacdec, um den QR-Code zu entschlüsseln:

$ ./vacdec "Adolf-Hitler-COVID-Zertifikat.png"
{-260: {1: {'dob': '1900-01-01',
            'nam': {'fn': 'HITLER',
                    'fnt': 'HITLER',
                    'gn': 'ADOLF',
                    'gnt': 'ADOLF'},
            'v': [{'ci': 'URN:UVCI:01:FR:T5DWTJYS4ZR8#4',
                   'co': 'FR',
                   'dn': 2,
                   'dt': '2021-10-01',
                   'is': 'CNAM',
                   'ma': 'ORG-100030215',
                   'mp': 'EU/1/20/1528',
                   'sd': 2,
                   'tg': '840539006',
                   'vp': 'J07BX03'}],
            'ver': '1.3.0'}},
 1: 'CNAM',
 4: 1697234400,
 6: 1635199742}

Die Felder sind hier dokumentiert (v1.3.0). Der Einfachheit halber hier wiedergegeben:

dob
Date of Birth
nam/fn
Surname
nam/fnt
Standardized Surname
nam/gn
Forename
nam/gnt
Standardized Forename
v/ci
Unique certificate identifier
v/co
Country
v/dn
Number in a series of doses
v/dt
Date of vaccination
v/is
Certificate Issuer (CNAM = Das cnam?)
v/ma
Marketing authorisation (der Impfhersteller)
v/mp
Vaccine product (das Impfprodukt)
v/sd
Overall number of doses (die technische Spezifikation erwähnt im Juni 2021 (!) bereits 3 im Falle eines Boosters …)
v/tg
Disease or agent targeted
v/vp
Vaccine or prophylaxis used

Hmmm, habe nach T5DWTJYS4ZR8 und J07BX03 in den JSONs gesucht, aber nichts gefunden. Die JSON-Listen führen also effektiv nur die vertrauenswürdigen Zertifikats-Issuer auf.

Tags: , , , , , , , , , , , ,
Labels: Gesundheit

2 Kommentare | neuen Kommentar verfassen

Dienstag, 12. Oktober 2021

Die Pravda … eh, der Blick, aus dem Hause Ringier zur selig machenden Zertifikatspflicht

Am 30. September 2021 titelte Blick, der verlängerte PR-Arm von Alain Berset und seinem Departement, auf Twitter:

Zertifikatspflicht brachte die Wende: Die vierte Welle ist gebrochen!

Die kritischen Geister da draussen wussten da aber schon längstens, dass sich die Fall- und Hospitalisationszahlen zum Zeitpunkt der Einführung der Zertifikatspflicht bereits seit Tagen im Sinkflug befanden.

Klickt man den Artikel heute an, sieht man, dass die Schlagzeile abgeschwächt wurde:

Zertifikatspflicht festigt die Wende: Die vierte Welle ist gebrochen!

Ich komme mir vor wie in der damaligen Sowjetunion, und empfinde das folgende Zitat als sehr zutreffend (fälschlicherweise Alexander Solschenizyn angedichtet, tatsächlich stammt die Aussage aber von Elena Gorokhova):

Wir wissen, sie lügen.
Sie wissen, sie lügen.
Sie wissen, dass wir wissen, sie lügen.
Wir wissen, dass sie wissen, dass wir wissen, sie lügen.
Und trotzdem lügen sie weiter.

Tags: , , , , ,
Labels: Gesundheit, Medien

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Ein Base64-enkodiertes Zertifikat im Klartext ausgeben

Wer ein Zertifikat im folgenden Format angezeigt erhält …

-----BEGIN CERTIFICATE-----
MIIFsDCCBJigAwIBAgISBMA6IcCIbuwMyJ+i4d6Wv7mOMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MTcwNzQ3MjZaFw0yMTEyMTYwNzQ3MjVaMCAxHj...

… macht es folgendermassen lesbar (certificate-b64.crt mit dem Pfad zum zwischengespeicherten Zertifikat ersetzen):

$ openssl x509 -in certificate-b64.crt -text -noout

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 8. August 2017

Google Chrome wieder nützliche Informationen über TLS-Verschlüsselung anzeigen lassen

Als Security Officer befasst man sich gelegentlich auch mit TLS-Zertifikaten von Web-Sites. Wenn man die Zertifikate und die Verschlüsselung einer im öffentlichen Internet ansprechbaren Web-Site bewerten lassen möchte, verwendet man dazu am Besten Qualys SSL Server Test.

Manchmal aber sind Web-Applikationen nur im Intranet erreichbar, oder manchmal möchte man einfach nur ganz rasch in Erfahrung bringen, welche Verschlüsselung eine Web-Site einsetzt.

Bis vor kurzem ging das in Chrome ganz flott: In der URL-Bar klickte man auf das Schloss-Symbol und erhielt mit ein, zwei Klicks alle nötigen Informationen präsentiert. Spätestens seit Version 59 klappt das nicht mehr.

In Version 60 haben die Chrome-Entwickler das Problem resp. den Kundenwunsch erkannt und ermöglichen es neu, die Funktionalität mittels einer Konfigurationseinstellung wieder zu reaktivieren:

  1. Chrome starten
  2. Die URL chrome://flags/#show-cert-link ansurfen
  3. Enable anklicken
  4. Chrome neu starten

Via: Configure Google Chrome to display certificates directly

Und ab sofort gibt es mit Klick auf das Schlosssymbol einer Web-Site wieder den Eintrag „Certificate“:

Mit Klick auf Valid öffnet sich danach ein os-spezifisches Fenster mit Informationen zum Zertifikat:

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. Februar 2017

imapfilter wechselnde Zertifikats-Fingerabdrücke ignorieren lassen

imapfilter funktioniert bei mir wunderbar, um in meiner INBOX eintreffende Mails automatisiert in Unterordner zu verschieben.

Dann und wann bricht das per Cron aufgerufene Script seine Arbeit aber ab, weil das Zertifikat des Mail-Servers gewechselt wurde:

imapfilter: certificate mismatch in non-interactive mode

imapfilter muss in einem solchen Fall interaktiv gestartet und das neue Zertifikat permanent akzeptiert werden.

Wen dieses Verhalten stört und die eindeutige Identifikation seiner Gegenseite weniger wichtig ist als ein sauber durchlaufendes Script, fügt oben an seine imapfilter-Regeln folgende Zeile ein:

...
options.certificates = false
...

Quelle: Ignore certificate fingerprint mismatch

Ich habe das bei mir nur für ein kaum genutztes Gmail-Konto aktiviert.

Das Problem könnte mit den hier geschilderten zwei gleichzeitig aktiven, unterschiedlichen Gmail-Zertifikaten zusammenhängen.

Tags: , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 4. Januar 2015

Remember The Milk lädt nicht mehr

Frisch zurück aus den Ferien kämpfte ich mit dem Zugriff auf meine Taskliste, welche ich mit der SaaS-Anwendung Remember The Milk verwalte. Wenn ich diese Seite in Safari aufrief, erschien einzig der blaue Hintergrund des Teasers, ohne dass aber die Lade-Animation erschien. In Firefox konnte ich mich problemlos in die Anwendung einloggen.

Ein Blick auf die Web Developer-Konsole in Safari gab mir einen ersten Hinweis, wo das Problem lag:

Safari Web Developer Console

Safari akzeptierte das SSL-Zertifikat für die Server s1.rtmcdn.net und s4.rtmcdn.net nicht (mehr). Offenbar hatte Firefox gleichzeitig kein Problem damit, die Server anzusprechen und Ressourcen von dort zu laden. Rückblickend vermute ich, dass Firefox eine eigene Liste vertrauenswürdiger CA Root-Zertifikate mitbringt und nicht auf die OS X-Zertifikate abstellt.

Nach etwas herumpröbeln entschied ich mich, Remember The Milk in Chrome zu öffnen. Der Google-Browser, welcher auch auf WebKit aufsetzt, lud die Applikation ebenfalls nicht, gab aber wenigstens eine deutlich klarere Fehlermeldung von sich:

Google Chrome SSL Error

… server presented a certificate that is not yet valid.

Hä? Irgendetwas war also definitiv mit dem Zertifikat nicht in Ordnung, welches von RTM eingesetzt wird. Ein Klick auf den durchgestrichenen https: zeigte mir Details zur Zertifikatskette an. Ich folgte der Kette bis zum Ursprung des Fehlers und sah folgende Fehlermeldung:

DigiCert High Assurance EV Root CA: This certificate has expired

Das Zertifikat ist seit dem 26. Juli 2014 nicht mehr gültig? Wieso ich in all dieser Zeit keine Probleme mit dem Zugriff auf RTM hatte, ist mir schleierhaft — evtl. haben die Entwickler erst kürzlich auf dieses Zertifikat gewechselt.

Das war die gesuchte Information. Mittels einer Google-Suche stiess ich äusserst rasch auf einen Blog-Artikel von DigiCert, der genau dieses Problem beschrieb und eine einfache Lösung anbot:

Fix for an Expired Intermediate SSL Certificate Chain

In meiner OS X Keychain war wie in den Screenshots von DigiCert beschrieben ein (abgelaufenes) DigiCert High Assurance EV Root CA abgelegt, welches problemlos gelöscht werden konnte. Keychain schliessen, Safari schliessen und neu öffnen — und ich konnte mich wieder in Remember The Milk einloggen.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 27. September 2012

Wenn imapfilter plötzlich mit meinem bei Cyon gehosteten Mail-Server nicht mehr funktioniert

Da verreise ich als auf einen IT-Audit ins „Ländle“, und prompt versagt mein geliebter imapfilter seinen Dienst. Fazit: Meine INBOXes sind plötzlich voller Mails, welche von imapfilter sonst schön brav spätestens 5 Minuten nach deren Ankunft auf meinen Mail-Konti in einen Unterordner verschoben werden. Zuerst dachte ich, dass mein lokaler Linux-Server, auf welchem imapfilter läuft, wegen eines Stromunterbruchs ausgefallen ist.

Doch mittels des äusserst nützlichen SSH-Clients Prompt hatte ich bereits am Dienstag realisiert, dass der Server am Netz hängt und ansprechbar ist.

Ein Blick in das von meinem imapfilter.sh-Script erzeugten Log zeigte, dass das Problem erstmals am Montag um 17 Uhr 15 Minuten aufgetaucht ist (Montag kurz vor Feierabend – dann scheinen die Cyon Sysadmins am liebsten ihre Zertifikate zu erneuern?)

2012-09-24 17:15 - <imapfilter Script> - Error '5' checking mail

Nun gut … letzter Ausweg: Ich versuche mich mittels

imapfilter -d -c <imapfilter Script>

interaktiv anzumelden und Debug-Meldungen abzulegen. Doch zur Analyse dieses Debug-Dumps kommt es nicht, denn auf der Kommandozeile strahlt mich folgender Hinweis an:

Server certificate subject: /OU=Domain Control Validated/CN=*.cyon.ch
Server certificate issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - G2
Server key fingerprint: 39:E9:08:A5:D9:EC:C3:A3:3E:0F:73:7C:14:B7:F2:A5
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Mittels Eingabe von p akzeptiere ich das neue Zertifikat, und gut isses.

Da hat Cyon also einfach nur sein Server-Zertifikat geändert. Wieso nimmt man immer gleich das Schlimmste an?

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen