Schl├╝ssel├╝bergabe

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.

F├╝gen Sie den ersten Kommentar hinzu