Proof
Laat regel voor regel zien wat eruit volgde.
Bij bestuurde interacties is in het product een compliancebon zichtbaar. Die legt vast wat het systeem heeft ontvangen, besloten en verstuurd: als hashes, geketend aan de vorige bon en samengebracht in een Merkle-wortel. Drie van die onderdelen kan iedereen met de bon in handen vandaag narekenen: geen sleutel, geen account, geen toegang tot onze database. De vijfde, de authenticatiecode, controleert u met de sleutel die wij aan uw tenant uitgeven.
Compliancebon
Doorgerekend voorbeeld- Invoerhash
0xfeb0ca5b0546ad8c…5092dcaeGeen sleutel nodig- Uitvoerhash
0x97d47018e45e19e1…83c557d9Geen sleutel nodig- Vorige bon
0xbfafe10889982fd2…09fe0579Geen sleutel nodig- Merkle-wortel
0x6e00080f64cff7d5…07658346In ontwikkeling- Authenticatiecode
0xfd73071e00fa7837…415b54aaTenantsleutel nodig
Doorgerekend voorbeeld. Acme GmbH en Nova Industries zijn verzonnen; hier staan geen klantgegevens. Dit zijn de waarden van de bon op /sample-receipt.json. /receipt-explorer rekent de drie sleutelvrije waarden na in uw eigen browser en vouwt het blad omhoog tot de Merkle-wortel die in datzelfde bestand staat; dat is iets anders dan hem afzetten tegen een buiten onze systemen gepubliceerde wortel.
Huidige bewijsstand
- Bon in het productZichtbaar
- Productie-exportWerkt vandaag
- Drie hashcontrolesOpenbaar
- Externe wortelpublicatieIn ontwikkeling
- Publieke controle van de uitgeverNiet beschikbaar
Vijf standen, niet één. Elk staat hieronder, met waar hij op rust.
Veld voor veld
Wat er in een bon staat
Een bon is één object per bestuurde handeling. Het meeste erin is een vastlegging: u kunt het aflezen, en dat aflezen vertelt u waar het systeem op dat moment van uitging. Vier velden gedragen zich anders: die kunt u narekenen, en een narekening klopt of klopt niet. Drie daarvan hebben niets anders nodig dan de bon; het vierde vouwt op tot de Merkle-wortel die de bon zelf draagt. Die naast een buiten onze systemen gepubliceerde wortel leggen, kan pas als wij de wortels publiceren.
- Veld
- receipt_id
- Wat het vastlegt
- De eigen kenmerkcode van de bon.
- Controle
- Aflezen
- Veld
- issued_at
- Wat het vastlegt
- Wanneer de bon is geschreven, volgens onze klok.
- Controle
- Aflezen
- Veld
- input
- Wat het vastlegt
- Wat de agent voorstelde: principaal, tegenpartij, agent, mandaat en versie, kanaal, rechtsgebied en bedrag.
- Controle
- Aflezen
- Veld
- input_hash
- Wat het vastlegt
- SHA-256 over het input-blok, zoals het systeem het ontving.
- Controle
- Narekenen
- Veld
- output
- Wat het vastlegt
- Wat er is besloten: de bevoegdheidspositie, de overschrijding, de beslissing en het vrijgavekenmerk.
- Controle
- Aflezen
- Veld
- output_hash
- Wat het vastlegt
- SHA-256 over het output-blok, zoals het systeem het vastlegde.
- Controle
- Narekenen
- Veld
- previous
- Wat het vastlegt
- De bon die ervoor is geschreven, in zijn vijf kernvelden: receipt_id, issued_at, input_hash, output_hash, previous_receipt_hash.
- Controle
- Aflezen
- Veld
- previous_receipt_hash
- Wat het vastlegt
- SHA-256 over precies die vijf velden. Juist dat maakt er een keten van.
- Controle
- Narekenen
- Veld
- receipt_hash
- Wat het vastlegt
- Dezelfde vijf velden van deze bon, gehasht. Die waarde is het blad waar de insluitingscontrole begint.
- Controle
- Aflezen
- Veld
- merkle.root · merkle.path · merkle.leaf_index
- Wat het vastlegt
- De wortel die deze bon zelf draagt, de zusterhashes op de weg daarheen, en de plaats van deze bon in de stapel. Hem afzetten tegen een buiten onze systemen gepubliceerde wortel wacht op die publicatie.
- Controle
- In ontwikkeling
- Veld
- auth.alg · auth.key_ref · auth.mac
- Wat het vastlegt
- HMAC-SHA256 over de canonieke bon, onder een symmetrische sleutel per tenant, en met welke sleutel hij is gemaakt.
- Controle
- Sleutel nodig
- Veld
- _sample · _disclaimer · _generated
- Wat het vastlegt
- De drie regels bovenaan het bestand: wat dit voorbeeld is, wat het niet vaststelt, en welk script het heeft geschreven.
- Controle
- Aflezen
Elke naam in deze kolom is een veld van het illustratieve voorbeeld op /sample-receipt.json, geschreven zoals het bestand het schrijft: open het bestand en ze staan er allemaal in. Waar benoemen zou betekenen dat er een veldpad verzonnen wordt, staat de regel niet in deze tabel.
De keten
Elke bon noemt de vorige.
Een bon staat niet op zichzelf. Voordat hij wordt geschreven gaat de hash van de vorige bon erin mee, zodat de bonnen van één tenant samen één geordende keten vormen.
Juist daardoor valt een wijziging op. Verander een waarde in een bon en zijn hash verandert; de bon erna draagt nog de oude, en die twee passen niet meer op elkaar. Niets hieraan houdt een wijziging tegen; het maakt een wijziging zichtbaar voor iedereen die de keten naloopt.
Bon RCP-899
- Draagt de hash van
0xc15f…df07- Eigen hash
0xe48f…5a07
Bon RCP-900
- Draagt de hash van
0xe48f…5a07- Eigen hash
0xbfaf…0579
Bon RCP-901
- Draagt de hash van
0xbfaf…0579- Eigen hash
0xc5a5…4b00
Als er één verandert
Elke bon daarna past niet meer, en de eerste afwijking noemt de plaats waar de keten is gebroken. Alleen toevoegen is hoe wij schrijven. Aantoonbaar is wat u kunt controleren.
Auditlog
Gebeurtenisketen waaraan alleen wordt toegevoegd. Een latere wijziging of herordening is aantoonbaar door de keten opnieuw te berekenen tegen het bewaarde commitment.
Insluiting
Reken de wortel zelf na.
Bonnen worden in stapels bijeengebracht, en een stapel wordt door telkens paren te hashen teruggebracht tot één wortel. De bon draagt zijn plaats in die stapel en de zusterhashes op de weg omhoog. Met die twee is de wortel uit de bon alleen na te rekenen.
- Weg vanaf deze bon
- Gebruikte zusterhashes
- Overige bonnen in de stapel
Vier stappen
- 1
Hash de vijf kernvelden
Neem receipt_id, issued_at, input_hash, output_hash en previous_receipt_hash, zet ze in één vaste vorm (sleutels alfabetisch, geen witruimte) en neem er de SHA-256 van. Die waarde is het blad, en de bon draagt hem als receipt_hash. Het is geen hash over de hele bon.
- 2
Reken de eerste zuster mee
Zet het blad en de eerste hash uit merkle.path terug in bytes, plaats de zuster aan de kant die haar veld side noemt, plak ze aan elkaar en neem de SHA-256 van het paar.
- 3
Loop omhoog
Herhaal dat voor elke volgende ingang in merkle.path, laag voor laag, tot er één waarde over is.
- 4
Vergelijk
Leg die waarde naast merkle.root. Gelijk betekent dat deze bon past bij de wortel die het bestand zelf draagt. Om te betekenen dat de bon toen in de stapel zat, moet die wortel worden afgezet tegen een buiten onze systemen gepubliceerd commitment, en die publicatie is in ontwikkeling.
Geen van die vier stappen gebruikt een sleutel: de bon en zijn pad zijn genoeg. Wat ze vaststellen is dat de bon past bij de wortel die hij zelf draagt. Een vijfde controle (die wortel tegen een buiten onze systemen gepubliceerd commitment) is in ontwikkeling.
Uit het illustratieve voorbeeld
- Veld
- receipt_hash
- Zoals gepubliceerd
- 0xc5a5788a435ffee6…fe3a4b00
- Veld
- merkle.leaf_index
- Zoals gepubliceerd
- 2
- Veld
- merkle.path
- Zoals gepubliceerd
- right · left · right
- Veld
- merkle.root
- Zoals gepubliceerd
- 0x6e00080f64cff7d5…07658346
Controle voor controle
Zeven controles, en ze zijn niet even beschikbaar.
Het Merkle-pad narekenen tot de wortel die een bon zelf draagt, is niet dezelfde controle als bevestigen dat die wortel vóór een bepaald moment buiten onze systemen is gepubliceerd. De eerste kunt u vandaag doen, in het uitgewerkte voorbeeld. De tweede kan niemand, want de wortels worden nog niet gepubliceerd. Elke regel hieronder noemt waar de controle op rust en waar hij staat.
- Controle
- De invoerhash narekenen
- Waar hij op rust
- SHA-256 over het input-blok van de bon die u in handen hebt. Meer is er niet voor nodig.
- Stand
- Beschikbaar
- Controle
- De uitvoerhash narekenen
- Waar hij op rust
- SHA-256 over het output-blok van hetzelfde bestand.
- Stand
- Beschikbaar
- Controle
- De koppeling met de vorige bon narekenen
- Waar hij op rust
- SHA-256 over de vijf kernvelden van de bon ervoor, die deze bon voluit meedraagt.
- Stand
- Beschikbaar
- Controle
- Het Merkle-pad narekenen tot de wortel die de bon zelf draagt
- Waar hij op rust
- Vouw het blad omhoog langs merkle.path en leg het naast merkle.root: de wortel die in hetzelfde bestand staat, niet een wortel die elders gevonden is. De stappen lopen vandaag op /sample-receipt.json; de productie-export werkt vandaag.
- Stand
- Beschikbaar in het uitgewerkte voorbeeld
- Controle
- Die wortel afzetten tegen een buiten onze systemen gepubliceerd commitment
- Waar hij op rust
- Publicatie van de wortels en het open eindpunt daarvoor zijn in ontwikkeling; de vierde controle kan zodra ze gepubliceerd zijn.
- Stand
- In ontwikkeling
- Controle
- Met alleen publieke cryptografie vaststellen wie de bon heeft uitgegeven
- Waar hij op rust
- De bon draagt HMAC-SHA256 onder een symmetrische sleutel per tenant. Een vrij toegankelijke sleutel om hem mee te controleren is er niet, dus er is voor een derde niets om tegen te controleren.
- Stand
- Niet beschikbaar
- Controle
- De uitgever eraan houden als hij ontkent hem geschreven te hebben
- Waar hij op rust
- Een authenticatiecode onder een gedeelde sleutel levert dat niet: wie hem kan controleren, kan hem ook maken, en wij houden diezelfde sleutel. Het is geen handtekening.
- Stand
- Niet geleverd door het huidige HMAC-ontwerp
/receipt-explorer voert de eerste vier hiervan uit op het uitgewerkte voorbeeld, in uw eigen browser. Geen enkele publieke dienst controleert vandaag een bon namens een derde.
Reken het zelf na
Drie gegevens, door iedereen na te rekenen.
Begin links: drie waarden die iedereen met een bon in handen kan narekenen, zonder sleutel en zonder ons. De vierde, de insluiting in de Merkle-wortel, kan zodra wij de wortels publiceren. Ernaast staat waar de tenantsleutel voor is en waar een bon een vastlegging van is. Juist daardoor kunt u de eerste kolom letterlijk nemen in plaats van op vertrouwen.
Drie gegevens, door iedereen na te rekenen
De invoerhash, de uitvoerhash, de koppeling met de vorige bon. De insluiting in de Merkle-wortel is de vierde controle; die kan zodra wij de wortels publiceren. Die publicatie en het open eindpunt daarvoor zijn in ontwikkeling.
Geen sleutel, geen account en geen toegang tot onze database: de rekensom loopt op de bon die u in handen hebt.
Waar de tenantsleutel voor is
De code is HMAC-SHA256 over de canonieke bon, onder een symmetrische sleutel per tenant. Het is een authenticatiecode en geen procedure met een openbare sleutel; een vrij toegankelijke sleutel om het na te rekenen is er niet.
Wie de code kan controleren, kan hem ook maken, en wij houden diezelfde sleutel. Hij toont dat de vastlegging ongeschonden is, niet wie haar heeft geschreven.
Waar een bon over gaat, en waar niet
Een bon is een getrouwe vastlegging van wat het systeem heeft ontvangen, besloten en verstuurd. Dat is wat hij vaststelt, niet of de werkelijkheid daarmee overeenkwam.
Gaf een beller een verkeerde naam op, dan legt de bon die verkeerde naam getrouw vast. Bewijs van het proces is geen bewijs van het feit, en geen enkele cryptografie dicht dat gat.
Doe het zelf
Haal een bon uit elkaar.
De explorer loopt het uitgewerkte voorbeeld veld voor veld na, met de voorbeeldbestanden ernaast. Niets daarvan vraagt om een account.
- Bonverkenner
Loop het uitgewerkte voorbeeld veld voor veld na.
- Voorbeeldbon (JSON)
Verzonnen partijen, echte rekensom: drie waarden rekenen zich na uit het bestand alleen, en de vierde vouwt op tot de Merkle-wortel die in datzelfde bestand staat.
- Voorbeeldbon (PDF)
Dezelfde vastlegging in een vorm die een functionaris gegevensbescherming kan lezen.
- Evidence Vault-API
Hoe bonnen worden geschreven en opgehaald.
- Hoe u hem narekent — de exacte vorm
De canonieke vorm, welk blok in welke waarde gaat, en vier testvectoren om op af te stellen. Geen code van ons.
Bewijsketen
Drie van die onderdelen kan iedereen met de bon in handen vandaag narekenen: geen sleutel, geen account, geen toegang tot onze database.
Het controleren van de authenticatiecode gebruikt de symmetrische sleutel die wij aan uw tenant uitgeven.
Control what AI can cause. Prove what follows.
Waar een bon vandaan komt
Een bon is wat een bestuurd gesprek achterlaat.
Voice is de toepassing waar hij uit komt: telefonie, de mededeling uit artikel 50 en het landbeleid op één plek, met een bon die voor bestuurde interacties zichtbaar is in het product. De bon die op deze pagina uit elkaar wordt gehaald draagt dezelfde velden en dezelfde rekensom.