Mening: Enterprise Blockchains Redux: Hvordan være ikke-ikke NIST-kompatibel uten å bryte banken

Uttalelse fra Andreas Freund, EEA Mainnet Interest Group Member

Blokkjeder har et sjeldent omtalt problem som er uavhengig av opp- og nedturer i kryptomarkeder, og som kan hindre blokkjedeadopsjon på lengre sikt utenfor direkte til forbruker og noen B2B-brukstilfeller: Blockchain kryptografiske algoritmer er ikke NIST-kompatible som er en viktig faktor for å oppnå samsvar med FISMA (Federal Information Security Management Act)! Og NIST/FISMA-overholdelse, eller ekvivalent derav utenfor USA, er en stor ting når bedrifter håndterer myndigheter eller bedrifter som regelmessig har å gjøre med bedrifter som har å gjøre med myndigheter.

Hvorfor er blokkjeder vanligvis ikke NIST-kompatible? Vel, hovedårsaken er at blokkjeder ble født ut av den dype mistilliten til alt som ble drevet av myndighetene og godkjent i kjølvannet av den store resesjonen i 2008; inkludert statlig godkjente kryptografiske algoritmer. Uansett ble SHA-3-hash-algoritmen som er allment akseptert i dag, ikke ferdigstilt før i 2015 etter at blokkjeder som Ethereum allerede hadde tatt sine valg om hashing-algoritmer. Derfor bruker de fleste blokkjeder som Ethereum algoritmer som ikke bare ikke er NIST-godkjent, men som NIST anbefaler å ikke bruke. Merk at det er NIST-kompatible blokkkjeder som Simba-Chain eller Fabric som opererer på IBMs LinuxONE. Imidlertid er de høye kostnader og vanskelige å administrere i produksjon[1]  som bedrifter lærte etter å ha brukt noen titalls millioner dollar på konsulent- og implementeringsgebyrer. Det som kompliserer kostnadsproblemet er at de ofte ikke gir de forventede forretningsresultatene fordi de valgte brukstilfellene ikke var egnet for Blockchains til å begynne med! Det viktigste for diskusjonen nedenfor er at enhver ny Enterprise Blockchain-tilnærming må adressere ikke bare NIST-overholdelse, men også både kostnads- og administrasjonskompleksitet effektivt for å tiltrekke seg nye forretningssponsorer.

Betyr det at alt er håpløst for Blockchain i en bedrift når NIST-overholdelse, kostnad og administrasjonskompleksitet er en bekymring?

Heldigvis er svaret nei, det er ikke håpløst. Ikke trivielt, men ikke håpløst.

For å forstå hva dette betyr, la oss oppsummere hvilke egenskaper Blockchain-baserte applikasjoner kan ha:

• Dataintegritet: Hvis du bare trenger det, så ikke bruk en Blockchain. Det finnes billigere alternativer.
• Påviselig tidsstempling: Mye mer interessant og nyttig for revisjonsspor, f.eks. på tvers av forsyningskjeder.
• Ingen enkeltpunktsfeil: Hvis du trenger 100 % tilgjengelighet, til en lav pris.
• Sensurmotstand: Tilgang til data som for eksempel må revideres av tredjeparter som ikke nødvendigvis er identifisert på tidspunktet for dataoppretting, eller utfører (i utgangspunktet) irreversible transaksjoner uavhengig av en tredjepart.
• Dobbeltbruksbeskyttelse: Bare relevant hvis du har å gjøre med digitale eiendeler på en Blockchain. Med andre ord, du er virkelig interessert i DeFi.
• Arver Blockchain-sikkerhetsgarantier: Den er veldig interessant hvis du trenger applikasjonsskalerbarhet, men likevel høy sikkerhet. Vi kommer til det om litt.

Legg merke til at ingen av de ovennevnte snakker om datavern, en av de uvurderlige juvelene til krav til bedriftsapplikasjoner. Men ingen grunn til bekymring, du kan oppnå personvern for data uten å plastre forretningssensitive data overalt ute i det fri. Vi kommer til det om litt også.

Før vi går i forkant, la oss ta en pause her og diskutere hvordan disse egenskapene relaterer seg til NIST-overholdelse. Ved første øyekast, ikke så mye, men la oss gå gjennom hver egenskap og diskutere implikasjonene litt mer detaljert. Først er det imidlertid verdt å nevne at for å få Authority-To-Operate (ATO) tillatelser fra en regjering, f.eks.[2], er det ok å bruke ikke-NIST-kompatible kryptografiske algoritmer, eller algoritmer som NIST ikke har dannet seg en mening om, så lenge disse algoritmene ikke er grunnleggende for sikkerheten til applikasjonen og personvernet til dataene. Du må for eksempel bevise at en kontrakt ble utført på en bestemt dag og ikke har blitt endret siden. Ved å bruke en blokkjede vil man danne et kryptografisk fingeravtrykk ved å bruke en (NIST-godkjent) kryptografisk hash av kontrakten, og deretter forankre denne hashen på en (offentlig) blokkjede som gir, når den er inkludert i en blokk, et bevisbart tidsstempel gjennom kombinasjonen av blokknummer, blokkhash og tidsstempel. Hvis blokkjeden ble omorganisert, for eksempel gjennom et 51%-angrep, ville det fortsatt være mulig å ta transaksjonen med kontraktshashen og blokkeringen og inkludere begge i en annen (offentlig) blokkjede. Derfor er sikkerheten til den originale (offentlige) Blockchain ikke grunnleggende for brukssaken.

Med dette i tankene, la oss se på nytt på hver egenskap, med fokus på dens innvirkning på NIST-overholdelse av en applikasjon som bruker Blockchain-teknologi:

• Dataintegritet: Denne er enkel siden du alltid kan ha en kopi av de relevante dataene du forankret, f.eks. via en kryptografisk hash på Blockchain med en annen form for dataintegritetsbeskyttelse, for eksempel en manipulerende W3C Verifiable Credential med en NIST-godkjent kryptografisk signaturalgoritme .
• Påviselig tidsstempling: Litt vanskeligere, men gjennomførbart. Hvis den brukte kjeden ble kompromittert, kunne man fortsatt ta blokken med den relevante transaksjonen som inneholder f.eks. en NIST-kompatibel kryptografisk hash av et dokument, og dets tidsstempel, og forankre hele blokken med transaksjonen gjennom en annen NIST-kompatibel kryptografisk hash på en annen Blockchain; ingen reell skade gjort.
• Ingen enkeltpunktsfeil: Ok, så dette er litt vanskelig siden NIST ikke har laget anbefalinger om konsensusalgoritmer. Det betyr at så lenge konsensusmodellen har et solid akademisk grunnlag, f.eks. et matematisk bevis på sikkerhet, kan den argumenteres med hell, og vi legger den i den ikke-ikke-NIST-kompatible bøtten.
• Sensurmotstand: Dette høres ut som en enkel en, men fordi det betyr at data vil være lett synlige for (nesten) alle deltakere, må det utvises stor forsiktighet for å bruke de riktige tilsløringsmetodene for data plassert på en Blockchain, for å kunne argumentere for at personvernet opprettholdes . Så den er litt vanskelig, men kan overvinnes. Hold ut, kommer rett opp.
• Dobbeltbruksbeskyttelse: Nå er denne virkelig vanskelig fordi den kombinerer de foregående punktene med deterministisk transaksjonsutførelse, transaksjonsvalidering og blokkdannelse som alle er avhengige av de kryptografiske algoritmene som brukes. Uten å gå inn på detaljer, hvis du trenger dobbeltbruksbeskyttelse som en nøkkelfunksjon i din Blockchain-baserte applikasjon, er du uheldig når det gjelder NIST-overholdelse … hvis din digitale eiendel ble født på Blockchain! Vi kommer tilbake til det punktet om et sekund også.
• Arver Blockchain-sikkerhetsgarantier: Dette ser ut til å være entydig. Hvis sikkerheten din er kritisk avhengig av sikkerheten til den underliggende Blockchain, og at Blockchain er avhengig av ikke-NIST-kompatible algoritmer for sin sikkerhet; slutten av historien. Igjen, ikke så fort. Spørsmålet er sikkerhetsgarantier for hva? Hvis det er for digitale eiendeler født på en Blockchain, så er svaret det samme som for Double-Spend-beskyttelse. Men hvis de digitale eiendelene først lages av Blockchain, og først deretter replikeres til Blockchain, er sikkerheten til den digitale eiendelen ikke lenger fundamentalt knyttet til den underliggende Blockchain, og vi har samme argument som for beviselig tidsstempling å vrikke oss ut av NIST-gåten!

Konsekvensanalysen ovenfor kan nå tjene som en sjekkliste mot en Blockchain-applikasjons NIST-samsvarsbehov, gitt de spesifikke brukskravene til den applikasjonen.

Før vi går videre og gir en applikasjonsoppskrift for en ikke-NIST-kompatibel Blockchain-basert applikasjon, la oss snakke om datavern. Gitt kriteriene ovenfor, og eksisterende personvernforskrifter, kvalifiserer det å plassere krypterte data på en Blockchain som en dum idé, selv når du bruker NIST-kompatible krypteringsalgoritmer. Så hva er alternativet?

Svar: Zero-Knowledge Proofs (ZKPs)

ZKP-er handler om å komme med uttalelser uten å avsløre underliggende sensitive data, f.eks. ACME-selskapets kontosaldo er over $100,000 XNUMX, eller denne rabattkoden ble riktig brukt på denne bestillingen.

Det finnes mange typer nyttige ZKP-er - Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, og så videre. Nøkkelen er å bruke enten NIST-kompatible eller ikke-NIST-kompatible kryptografiske algoritmer når du bruker ZKP-er. Ellers, gå for det! ZKP-er er et flott verktøy for bedrifter for å oppfylle kravene til personvern både internt og regulatorisk.

Nå er vi på et sted for å komme med en fornuftig anbefaling om hvordan man bygger en (ikke-ikke) NIST-kompatibel Blockchain-basert bedriftsapplikasjon – en blåkopi.

Faktiske distribusjons- og driftskostnader er ikke offentlig tilgjengelige, men basert på forfatterens kunnskap går det mellom åtte og fine tall i USD med driftskostnader typisk i området 15 – 25 % – se også noen referanser her. og her.. Disse kostnadsområdene er typiske for storskala enterprise systemimplementeringer og operasjoner som ERP-systemer.

Med opprinnelse fra FISMA Act og OMB-sirkulære A-130, er det byråers ansvar å sikre at risikoen ved å bruke et informasjonssystem til å utføre aktiviteter som tilgang, overføring, lagring, behandling av føderale data er bestemt og akseptert og at en ATO er godkjent for slike systemer.

Som figuren viser, starter vi med en tradisjonell bedriftsprogramvarestabel på toppen – først applikasjonslaget, deretter applikasjonsabstraksjonslaget og deretter mellomvarelaget – med all nødvendig samsvar, f.eks. NIST-samsvar innebygd. På bunnen av stabelen har vi en offentlig Blockchain fordi det fjerner behovet for bedrifter til å bygge komplekse konsortier, bruke mye penger og la dem bevege seg mye raskere med utviklingen av nye produkter. Mellom mellomvaren og det offentlige Blockchain-laget er det "magiske" behandlingslaget fokusert på personvern og hastighet. Siden stabelen vil bruke personvernbevarende ZKP-er og ikke primært bruke digitale eiendeler opprettet på den offentlige Blockchain, er tidligere bekymringer om bruken av offentlige Blockchains plutselig borte. Som opp- og nedpilene til venstre i figuren indikerer, øker stabelsikkerheten når vi går fra topplaget til bunnen, den offentlige Blockchain. Det stikk motsatte skjer med de tre andre nøkkelegenskapene – personvern, hastighet og kontroll; de øker fra det nederste laget til det øverste laget hvor en enkelt bedrift har full kontroll over alle data, og kan derfor sikre personvern samtidig som de opprettholder høy hastighet/skalerbarhet selv for de mest sensitive dataene. Det betyr imidlertid ikke at personvern, hastighet og kontroll er lavt mot bunnen av stabelen, det betyr bare at det er høyere i de øverste lagene av stabelen enn nederst.

Nå, hva med det "magiske" behandlingslaget/nettverket?

Her er hva det laget kan gjøre ved å bruke eksisterende teknologi for å møte bedriftens krav:

• Datasikkerhet
  • Nullkunnskapsbevis for transaksjoner
  • Sterk kryptering (der det er nødvendig)
  • Siste kryptografiteknikker, f.eks. kvantesikre algoritmer
• Sikkerhet
  • Arver sikkerhetsgarantiene fra den offentlige Blockchain ved bruk av riktige ZKP-er forankret på Blockchain
  • Digitale aktivadata kan være direkte tilgjengelige via ZKP-er på den offentlige Blockchain for å brukes om nødvendig
• etterprøvbarhet
  • Hvem som helst kan verifisere bevis på den offentlige Blockchain
  • Bevis kan rekursivt verifisere alle aktivatransaksjoner og hele aktivatransaksjonshistorikken
  • Ingenting er ferdigstilt før bevis er bekreftet på den offentlige Blockchain
• Speed
  • Parallellisering av transaksjoner
  • Rulle opp transaksjoner ved å gruppere dem med (rekursive) bevis
  • Mindre kostnad per transaksjon

Oppsummert har det "magiske" behandlingslaget

• de samme sikkerhetsgarantiene som den offentlige Blockchain brukte,
• 100 – 1000 ganger mer skalerbarhet,
• garantert datatilgjengelighet,
• personvernet ivaretas til enhver tid,
• mye lavere transaksjonsgebyrer,
• verifiserbarhet av alle bevis av alle på den offentlige Blockchain
• gir mulighet for KYC og AML

Dette høres for godt ut til å være sant. Finnes slik teknologi allerede? Svaret er ja, og selskaper som Starkware, Aztec, zkSync og andre jobber med å få deres ZK-Rollup "Layer 2"-teknologier helt bedriftsklare. Fokuset for alle disse anstrengelsene er offentlige Ethereum fordi det tilbyr de høyeste sikkerhetsgarantiene (antall gruvearbeidere/validatorer og total-verdi-låst (TVL)), kombinert med den nødvendige kryptografiske støtten innebygd i utførelseslaget.

Naturligvis er dette ikke den eneste mulige tilnærmingen for en Blockchain-basert applikasjon for å få en statlig ATO. Det er imidlertid en ganske grei, og nå godt forstått tilnærming.

Så hva er nettnettet her?

Bedrifter har nå

• A rammeverk å vurdere brukscasebehov kontra Blockchain-egenskaper, og hvordan disse behovene kan dekkes av Blockchain-baserte bedriftsapplikasjoner som kan få en statlig ATO.
• A blåkopi å bygge Blockchain-baserte bedriftsapplikasjoner på en måte som vil tillate dem å få en statlig ATO, samtidig som det, som vist i figuren ovenfor, også gir mulighet for ytterligere fordeler:
  • Høyere tillit gjennom offentlige blokkjeder, offentlig etterprøvbarhet og kryptografi håndhevet personvern
  • Lavere kostnad gjennom enklere revisjonerbarhet (å bekrefte at ZKP-er er rask og billig) og fancy transaksjonsbatching (sammendrag) i Layer 2-applikasjonen
  • Raskere behandling gjennom parallellisering av databehandling, flere transaksjoner gjennom sammenrullinger og et mindre Blockchain-fotavtrykk siden offentlige blokkjeder er ment å være trege av design for å gi mer sikkerhet
  • Mer fleksibilitet og valgmuligheter gjennom muligheten til å ha tradisjonelle eiendeler for å underbygge kryptoaktiva på Blockchain, enklere integrasjon mellom Layer 2 og en offentlig Blockchain, og enkel utvidelse av lag 2-eiendeler til for eksempel de eksisterende DeFi-økosystemene

Avslutningsvis er det viktig å merke seg at i eksemplet med den amerikanske regjeringen, er det å skaffe en ATO for et informasjonssystem ikke bare begrenset til kryptografiske artefakter og kryptomoduler. Disse representerer en viktig del av sikkerhetskontrollene som identifiseres under risikostyringsprosessen som er nødvendig for å skaffe en ATO, som oppført og forklart i omfattende detalj i NIST SP 800-37 Rev 2 og NIST FIPS-199. Prosessen inkluderer også elementer som brukerautentisering/autorisasjon under ulike bruksscenarier, system- og prosessendringskontroller, katastrofegjenoppretting og forretningskontinuitet.

Er ATO/NIST-samsvar for Blockchain-applikasjoner relevant for virksomheten din? EEA ATO-arbeidsgruppen vil gjerne ha innspill fra deg. Vær så snill og kontakt .

Følg oss på Twitter, Linkedin og  Facebook  for å holde deg oppdatert på alt som har med EØS å gjøre.