Cryptografie uitgelegd

Sleuteltransparantie en Merkle-bomen

Sleuteltransparantie legt koppelingen tussen identiteiten en publieke sleutels vast in een controleerbare append-only structuur. Merkle-bewijzen maken records en wijzigingen verifieerbaar. [1]

Beoordeeld 3 primaire of first-party bronnen Geschreven door SealTask

Kernpunten

  • Een inclusiebewijs bindt een vermelding aan een specifieke boomwortel.
  • Een consistentiebewijs toont aan dat de historie alleen is uitgebreid.
  • Ondertekende checkpoints wijzen een controleerbare logstatus aan.
  • Gossip of onafhankelijke waarneming versterkt bescherming tegen split views.

Definitie en reikwijdte

Een kwaadwillende sleuteldirectory kan berichten omleiden door ongemerkt een openbare sleutel te vervangen. Sleuteltransparantie bindt identiteit-sleutelkoppelingen aan een controleerbare logstatus, zodat clients opname en veranderingen kunnen toetsen. [1]

Beveiligingsgrens

Merkle-inclusiebewijzen tonen dat een blad bij een wortel hoort; consistentiebewijzen tonen dat een nieuwe status de oude ongewijzigd uitbreidt. Geen van beide vervangt initiële identiteitscontrole of behoorlijk beheer van de log. [1][2]

Beperkingen en beoordeling

Een beheerder kan geïsoleerde clients verschillende maar intern consistente geschiedenissen tonen als checkpoints nooit worden vergeleken. Verdediging tegen split views vereist gossip of onafhankelijke monitors; ook het eerste geaccepteerde checkpoint is een vertrouwensgrens. [1][2]

Veelgestelde vragen.

Wat betekent Sleuteltransparantie en Merkle-bomen?

Sleuteltransparantie legt koppelingen tussen identiteiten en publieke sleutels vast in een controleerbare append-only structuur. Merkle-bewijzen maken records en wijzigingen verifieerbaar. [1]

Wat garandeert Sleuteltransparantie en Merkle-bomen niet?

Een beheerder kan geïsoleerde clients verschillende maar intern consistente geschiedenissen tonen als checkpoints nooit worden vergeleken. Verdediging tegen split views vereist gossip of onafhankelijke monitors; ook het eerste geaccepteerde checkpoint is een vertrouwensgrens. [1][2]

Hoe plaatst SealTask Sleuteltransparantie en Merkle-bomen?

SealTask registreert openbare sleutels van genodigden in een append-only Merkle-boom en controleert inclusie en consistentie. Eerste gebruik, checkpoint-reset en het huidige ontbreken van onafhankelijke monitoring zijn gedocumenteerde beperkingen. [3]

Primaire bronnen

Definities geven voorrang aan standaardisatieorganisaties, overheidsrichtlijnen en de first-party architectuur van SealTask. Links openen de volledige bron.

  1. 01
    IETF Key Transparency Protocol Primaire of first-party bron voor de definitie, protocolvereisten, beveiligingsgrens of regelgevende context.
  2. 02
    RFC 9162: Certificate Transparency Version 2.0 Primaire of first-party bron voor de definitie, protocolvereisten, beveiligingsgrens of regelgevende context.
  3. 03
    SealTask security architecture Primaire of first-party bron voor de definitie, protocolvereisten, beveiligingsgrens of regelgevende context.
Bekijk het volledige kenniscentrum