Warum vertrauen wir Zertifizierungsstellen?

Im August 2011 berich­tet ein irani­scher In­ternetnutzer von ei­ner Brow­ser-War­nung, wenn er sich zu sei­nem Gmail-Konto einloggen will. Der Nutzer des Chro­me-Browsers wendet sich damit in ei­nem Forum direkt an Goog­le und fragt, ob es sich um ei­nen MITM-Angriff auf die VerschlĂŒsselung handeln könnte. Goog­le un­tersucht dar­aufhin die Si­tuati­on und bestĂ€tigt sei­ne Vermu­tung: es gab Angriffe auf die VerschlĂŒsselung der Kommunikati­on, wovon primĂ€r In­ternetnutzer im Iran betroffen wa­ren. Die Zertifizierungs­stel­le DigiNo­tar habe un­ter an­de­rem fĂŒr goog­le.com nicht autorisier­te Zertifikate aus­ge­stellt, die von Browsern an­stands­los akzep­tiert wur­den. Allein der kurz vor dem Vorfall veröff­entlich­ten Si­cherheits­funkti­on des Chro­me-Browsers sei es zu ver­danken, dass das missbrĂ€uch­lich verwende­te Zertifikat bemerkt wurde. Die neue Si­cherheits­funkti­on prĂŒfe fĂŒr den Goog­le E-Mail-Dienst Gmail nicht nur, ob das Zertifikat gĂŒltig ist, sondern auch ob es von ei­ner autorisier­ten Zertifizierungs­stel­le aus­ge­stellt wurde.
In Chro­me und an­de­ren Browsern wur­den sofort alle Zertifikate ge­sperrt, die von DigiNo­tar aus­ge­stellt wur­den. Die Zertifizierungs­stel­le, die seit Juli 2011 von den nicht autorisier­ten Zertifika­ten fĂŒr Domains von Goog­le, dem CIA, dem Mossad, dem MI6 und an­de­ren wusste, wurde unter die Aufsicht nieder­lĂ€ndi­scher Behörden gestellt und es wurde ein Ermittlungs­verfah­ren ein­ge­leitet.

Weshalb wir auf Zertifizierungs­stel­len angewiesen sind

Der Fall von DigiNo­tar wiegt schwer und lĂ€sst die Fra­ge auf­kommen, weshalb es ĂŒberhaupt Zertifizierungs­stel­len gibt. Um dies zu ver­stehen, be­trach­ten wir zu­nĂ€chst verschlĂŒsselte Kommunikati­on im Allgemei­nen. Möch­ten die zwei Kommunikati­ons­partner Alice und Bob si­cher mit­ein­an­der kommunizie­ren, mĂŒs­sen sie sich zu­nĂ€chst auf ein VerschlĂŒsselungs­verfah­ren einigen, das nach heutigen MaßstĂ€­ben als si­cher erach­tet wird. Das bedeu­tet, dass kei­ne Wege bekannt sein dĂŒrfen, durch die die VerschlĂŒsselung in akzep­ta­bler Zeit gebro­chen wer­den kann. An­schließend mĂŒs­sen sich bei­de auf ei­nen geheimen SchlĂŒs­sel (bei­spielsweise ein Kennwort aus Buchsta­ben und Zah­len) einigen. HierfĂŒr existie­ren Verfah­ren, wodurch Alice und Bob ei­nen gemeinsamen SchlĂŒs­sel ver­einba­ren können, ohne sich selbst persönlich treffen oder den SchlĂŒs­sel durch ei­nen Bo­ten aus­tau­schen las­sen zu mĂŒs­sen. Mit dem SchlĂŒs­sel, den Alice durch ein sol­ches Verfah­ren erhal­ten hat, könnte sie Bob nun ei­ne verschlĂŒsselte In­formati­on zusen­den. Doch ei­ne Fra­ge bleibt bei diesen Verfah­ren offen: stammt der SchlĂŒs­sel tatsĂ€chl­ich von Bob?

Ab­bildung 1 zeigt ei­ne Si­tuati­on, in der SchlĂŒs­sel aus­ge­tauscht wer­den. Alice erhĂ€lt ei­nen SchlĂŒs­sel und geht davon aus, dass die­ser von Bob stammt (und umgekehrt aus der Sicht von Bob). TatsĂ€chl­ich jedoch klinkt sich der Angreifer Mall­ory in die Kommunikati­on ein und sendet Alice und Bob jeweils sei­nen SchlĂŒs­sel. Alice und Bob ha­ben kei­ne Möglichkeit mit Si­cherheit festzu­stel­len, ob sie den richtigen SchlĂŒs­sel besit­zen.

AuthentizitĂ€t beim SchlĂŒsselaustausch, Mallory als Man in the Middle
Ab­bildung 1 Mall­ory gibt sich als der jeweilige an­de­re Kommunikati­ons­partner aus, um so die verschlĂŒsselte Kommunikati­on abhören zu können.

Dieses Au­thentizitĂ€ts­p­roblem kann durch vertrau­enswĂŒrdige Zertifizierungs­stel­len gelöst wer­den, denen alle Kommunikati­ons­teilneh­mer vertrau­en. Jeder Teilneh­mer lĂ€sst sei­nen SchlĂŒs­sel von der Zertifizierungs­stel­le si­gnie­ren. Den SchlĂŒs­sel und die Si­gnatur ver­sen­den die Teilneh­mer als Zertifikat an die Ge­gen­stel­le. Die­se kann die Si­gnatur prĂŒfen und die Echt­heit des SchlĂŒs­sels bestĂ€tigen. Ab­bildung 2 zeigt die­se Si­tuati­on fĂŒr Alice und Bob: Bob lĂ€sst sei­nen SchlĂŒs­sel von der Zertifizierungs­stel­le si­gnie­ren und sendet ihn Alice. Alice vertraut auf die PrĂŒfung durch die Zertifizierungs­stel­le; sie kann sich durch die Si­gnatur si­cher sein, dass sie Bobs SchlĂŒs­sel erhal­ten hat. Mall­ory kann sich mit sei­nem SchlĂŒs­sel nicht als Bob aus­ge­ben, da er hierfĂŒr kei­ne gĂŒltiges Zertifikat vorweisen kann.

Austausch signierter, vertrauenswĂŒridiger SchlĂŒssel
Ab­bildung 2 Bob sendet sei­nen si­gnier­ten öff­entli­chen SchlĂŒs­sel. Alice kann die Echt­heit von Bobs SchlĂŒs­sel ĂŒber­prĂŒfen. Mall­ory kann sich nicht als Bob aus­ge­ben.

Im World Wide Web findet der Aus­tausch von SchlĂŒs­seln fĂŒr ei­ne si­che­re Kommunikati­on Ă€hnlich statt. Ein Web­seitenbe­treiber weist fĂŒr sei­ne Domain, bei­spielsweise example.com, den Besitz gegenĂŒber der Zertifizierungs­stel­le nach. Die­se stellt ihm dafĂŒr ein Zertifikat aus, das der Web­seitenbe­treiber fĂŒr die verschlĂŒsselte Kommunikati­on mit sei­nen Benutzern verwendet. Da die Benutzer (vielmehr ihre Brow­ser) al­len gĂŒltigen Zertifika­ten der Zertifizierungs­stel­le vertrau­en, können sie die Echt­heit des SchlĂŒs­sels bestĂ€tigen und ihn verwen­den.

Zertifizierungs­stel­len sind ei­ne wesentli­che Komponente in diesem Vertrau­ensmodell. Von ihnen gibt es welt­weit meh­re­re Dutzend. Nutzer des Browsers Fi­refox bei­spielsweise vertrau­en implizit 92 Zertifizierungs­stel­len (Stand 20.03.2017). Doch wie im Bei­spiel von DigiNo­tar ein­gangs erwĂ€hnt, gibt es Zertifizierungs­stel­len, die – gewollt oder un­gewollt – nicht autorisier­te Zertifikate aus­stel­len. Der Fall von DigiNo­tar ist nĂ€mlich kein Ein­zelfall; an­de­re Bei­spiele sind DigiCert (2011), das Natio­nal In­formatics Cent­re of India (2014), Comodo (2015), Thawte (2015), Symantec (2017), WoSi­gn (diverse) et cete­ra. Die GrĂŒn­de fĂŒr das Aus­stel­len nicht autorisier­ter Zertifikate sind vielfĂ€ltig. Sie rei­chen von ei­ner Miss­ach­tung von Stan­dards ĂŒber gehack­te Zertifizierungs­stel­len bis hin zu Missbrauch durch Geheimdienste oder Regierun­gen.

Kommt ein Angreifer in den Besitz ei­nes nicht autorisier­ten aber gĂŒltigen Zertifikats, sind verschlĂŒsselte Ver­bindun­gen nicht mehr si­cher. Der Angreifer wĂŒrde sich mit ei­nem Man-in-the-Middle-Angriff zwi­schen zwei Kommunikati­ons­partner set­zen und das gĂŒltige Zertifikat prĂ€sentie­ren. Dieses wird akzep­tiert, da der Client Zertifika­ten der nicht mehr vertrau­enswĂŒrdigen Zertifizierungs­stel­le vertraut. Die Kommunikati­on wird abgehört.

Ab­si­cherung gegen fal­sche Zertifikate

Das Pro­blem mit Zertifika­ten ist nicht neu. Aus diesem Grund wur­den in der Vergan­genheit meh­re­re Möglichkei­ten zur Ab­si­cherung gegen fal­sche Zertifikate vor­ge­schla­gen. Die­se können in die folgen­den vier Klas­sen ein­ge­teilt wer­den:

  1. DNS-basier­te An­sĂ€t­ze
    • Certificati­on Aut­hority Aut­horizati­on (CAA)
    • DNS-based Au­thenti­cati­on of Named En­t­i­ties (DANE)
  2. Notar-basier­te An­sĂ€t­ze
    • Perspectives
    • Convergence
  3. Pin­ning-basier­te An­sĂ€t­ze
    • HTTP Public Key Pin­ning (HPKP)
    • Trust Asserti­ons for Certificate Keys (TACK)
    • DNSChain
  4. Trans­pa­renz-basier­te An­sĂ€t­ze

Die auf­gezĂ€hl­ten Verfah­ren wer­den in nach­folgen­den Artikeln beschrie­ben und mit­ein­an­der ver­gli­chen.

Blin­des Vertrau­en gegenĂŒber Zertifizierungs­stel­len?!

In diesem Bei­trag wurde erklĂ€rt, wel­che Rolle Zertifizierungs­stel­len fĂŒr verschlĂŒsselte Kommunikati­on spie­len. Sie bestĂ€tigen durch Zertifikate die Au­thentizitĂ€t von SchlĂŒs­seln. Die Vergan­genheit hat jedoch gezeigt, dass auch nicht autorisier­te Zertifikate aus­ge­stellt wur­den und demnach offenbar nicht alle Zertifizierungs­stel­len vertrau­enswĂŒrdig sind. Ein blin­des Vertrau­en gegenĂŒber diesen Stel­len wĂ€re also falsch, weshalb neue Verfah­ren ent­wickelt wer­den, um das Sys­tem zu ver­bes­sern. Die­se Verfah­ren wer­den in zukĂŒnftigen Bei­trĂ€gen im aramido-Blog vor­ge­stellt und diskutiert.