Udtalelse: Enterprise Blockchains Redux: Sådan er du ikke-ikke NIST-kompatibel uden at bryde banken

Udtalelse fra Andreas Freund, EEA Mainnet Interest Group Member

Blockchains har et sjældent omtalt problem, som er uafhængigt af op- og nedture på kryptomarkederne, og som kan hæmme blockchain-adoption på længere sigt uden for direkte-til-forbruger og nogle B2B-brugssager: Blockchain-krypteringsalgoritmer er ikke NIST-kompatible, hvilket er en væsentlig faktor for at opnå overholdelse af FISMA (Federal Information Security Management Act)! Og NIST/FISMA-overholdelse, eller tilsvarende deraf uden for USA, er en stor ting, når virksomheder handler med regeringer eller virksomheder, der regelmæssigt handler med virksomheder, der handler med regeringer.

Hvorfor er Blockchains typisk ikke NIST-kompatible? Nå, hovedårsagen er, at Blockchains blev født ud af den dybe mistillid til alt, der drives af regeringen og godkendt i kølvandet på den store recession i 2008; herunder statsgodkendte kryptografiske algoritmer. Under alle omstændigheder blev SHA-3 hashing-algoritmen, der er bredt accepteret i dag, først færdiggjort i 2015, efter at Blockchains såsom Ethereum allerede havde truffet deres valg om hashing-algoritmer. Derfor bruger de fleste Blockchains såsom Ethereum algoritmer, der ikke kun ikke er NIST-godkendte, men som NIST anbefaler ikke at bruge. Bemærk, der er NIST-kompatible Blockchains såsom Simba-Chain eller Fabric, der opererer på IBM's LinuxONE. De er dog høje omkostninger og svære at håndtere i produktionen[1]  som virksomheder lærte efter at have brugt nogle titusindvis af millioner dollars på konsulent- og implementeringsgebyrer. For at forene omkostningsproblemet er, at de ofte ikke giver de forventede forretningsresultater, fordi de valgte use cases ikke var egnede til Blockchains til at begynde med! Det vigtigste ved diskussionen nedenfor er, at enhver ny Enterprise Blockchain-tilgang skal adressere ikke kun NIST-overholdelse, men også både omkostninger og administrationskompleksitet effektivt for at tiltrække nye virksomhedssponsorer.

Betyder det, at alt er håbløst for Blockchain i en virksomhed, når NIST-overholdelse, omkostninger og administrationskompleksitet er et problem?

Heldigvis er svaret nej, det er ikke håbløst. Ikke trivielt, men ikke håbløst.

For at forstå, hvad dette betyder, lad os opsummere, hvilke karakteristika Blockchain-baserede applikationer kan har:

• Dataintegritet: Hvis du kun har brug for det, så brug ikke en Blockchain. Der er billigere alternativer.
• Beviselig tidsstempling: Meget mere interessant og nyttig til revisionsspor, f.eks. på tværs af forsyningskæder.
• Ingen single-point-of-failure: Hvis du har brug for 100 % tilgængelighed, til en lav pris.
• Censurmodstand: Adgang til data, der for eksempel skal revideres af 3. parter, der ikke nødvendigvis er identificeret på tidspunktet for dataoprettelse, eller udfører (dybest set) irreversible transaktioner uafhængigt af enhver 3. part.
• Dobbeltforbrugsbeskyttelse: Kun relevant, hvis du har med digitale aktiver at gøre på en Blockchain. Du er med andre ord virkelig til DeFi.
• At arve Blockchain-sikkerhedsgarantier: Den er meget interessant, hvis du har brug for applikationsskalerbarhed, men alligevel høj sikkerhed. Det kommer vi til om lidt.

Bemærk, at ingen af ​​ovenstående taler om databeskyttelse, en af ​​de uvurderlige juveler af krav til virksomhedsapplikationer. Men ingen bekymringer, du kan opnå databeskyttelse uden at plastre virksomhedsfølsomme data overalt i det fri. Det kommer vi også til om lidt.

Før vi går foran os selv, lad os stoppe her og diskutere, hvordan disse karakteristika relaterer til NIST-overholdelse. Ved første øjekast ikke så meget, men lad os gennemgå hver egenskab og diskutere dens implikationer lidt mere detaljeret. Først er det dog værd at nævne, at for at opnå Authority-To-Operate (ATO) tilladelser fra en regering, f.eks. den amerikanske regering[2], er det ok at bruge ikke-NIST-kompatible kryptografiske algoritmer, eller algoritmer som NIST ikke har dannet sig en mening om, så længe disse algoritmer ikke er fundamentale for applikationens sikkerhed og fortroligheden af ​​dens data. For eksempel skal du bevise, at en kontrakt blev udført på en bestemt dag og ikke er blevet ændret siden. Ved at bruge en Blockchain ville man danne et kryptografisk fingeraftryk ved at bruge en (NIST-godkendt) kryptografisk hash af kontrakten, og derefter forankre denne hash på en (offentlig) Blockchain, som giver, når den er inkluderet i en blok, et bevisbart tidsstempel gennem kombinationen af bloknummer, blokhash og tidsstempel. Hvis Blockchain blev reorganiseret, for eksempel gennem et 51%-angreb, ville det stadig være muligt at tage transaktionen med kontrakthashen og dens blokering og inkludere begge i en anden (offentlig) Blockchain. Derfor er sikkerheden i den originale (offentlige) Blockchain ikke grundlæggende for use casen.

Med dette i tankerne, lad os se igen på hver egenskab med fokus på dens indvirkning på NIST-overholdelse af en applikation, der bruger Blockchain-teknologi:

• Dataintegritet: Denne er nem, da du altid kan have en kopi af de relevante data, du har forankret f.eks. via en kryptografisk hash på Blockchain med en anden form for dataintegritetsbeskyttelse, såsom en manipulationssikker W3C Verifiable Credential med en NIST-godkendt kryptografisk signaturalgoritme .
• Beviselig tidsstempling: Lidt sværere, men gennemførligt. Hvis den anvendte kæde blev kompromitteret, kunne man stadig få fat i blokken med den relevante transaktion indeholdende f.eks. en NIST-kompatibel kryptografisk hash af et dokument og dets tidsstempel, og forankre hele blokken med transaktionen gennem en anden NIST-kompatibel kryptografisk hash på en anden Blockchain; ingen reel skade sket.
• Ingen single-point-of-failure: Ok, så dette er lidt vanskeligt, da NIST ikke har dannet anbefalinger om konsensusalgoritmer. Det betyder, at så længe konsensusmodellen har et solidt akademisk fundament, f.eks. et matematisk bevis på sikkerhed, kan det med held argumenteres for, og vi lægger det i den ikke-ikke-NIST-kompatible bøtte.
• Censurmodstand: Dette lyder som en let en, men fordi det betyder, at data vil være let synlige for (næsten) alle deltagere, skal man være meget omhyggelig med at bruge de rigtige sløringsmetoder for data, der er lagt på en Blockchain, for med succes at argumentere for, at databeskyttelse bevares . Så den ene er lidt tricky, men kan overvindes. Hold godt fast, kommer lige op.
• Dobbeltforbrugsbeskyttelse: Nu er denne virkelig svær, fordi den kombinerer de foregående punkter med deterministisk transaktionsudførelse, transaktionsvalidering og blokdannelse, som alle i høj grad er afhængige af de anvendte kryptografiske algoritmer. Uden at gå i detaljer, hvis du har brug for dobbeltforbrugsbeskyttelse som en nøglefunktion i din Blockchain-baserede applikation, er du uheldig med hensyn til NIST-overholdelse … hvis dit digitale aktiv blev født på Blockchain! Vi vender også tilbage til det punkt om et sekund.
• At arve Blockchain-sikkerhedsgarantier: Dette ser ud til at være entydigt. Hvis din sikkerhed er kritisk afhængig af sikkerheden af ​​den underliggende Blockchain, og denne Blockchain er afhængig af ikke-NIST-kompatible algoritmer for sin sikkerhed; slutningen af ​​historien. Igen, ikke så hurtigt. Spørgsmålet er sikkerhedsgarantier for hvad? Hvis det er for digitale aktiver født på en Blockchain, så er svaret det samme som for Double-Spend-beskyttelse. Men hvis de digitale aktiver først skabes ud af Blockchain og først derefter replikeres til Blockchain, er sikkerheden for det digitale aktiv ikke længere bundet grundlæggende til den underliggende Blockchain, og vi har samme argument som for beviselig tidsstempling at vrikke os ud af NIST-gåden!

Ovenstående konsekvensanalyse kan nu tjene som en tjekliste i forhold til en Blockchain-applikations NIST-overholdelsesbehov, givet de specifikke brugscasekrav for den applikation.

Før vi går videre og giver en applikationsplan for en ikke-NIST-kompatibel Blockchain-baseret applikation, lad os tale om databeskyttelse. I betragtning af ovenstående kriterier og eksisterende regler om databeskyttelse, kvalificerer det at placere selv krypterede data på en Blockchain som en dum idé, selv når du bruger NIST-kompatible krypteringsalgoritmer. Så hvad er alternativet?

Svar: Zero-Knowledge Proofs (ZKP'er)

ZKP'er handler om at komme med erklæringer uden at afsløre underliggende følsomme data, f.eks. er ACME Corporations kontosaldo over $100,000, eller denne rabatkode blev korrekt anvendt på denne ordre.

Der er mange typer nyttige ZKP'er – Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, og så videre. Nøglen er at bruge enten NIST-kompatible eller ikke-NIST-kompatible kryptografiske algoritmer, når du bruger ZKP'er. Ellers gå til det! ZKP'er er et fantastisk værktøj for virksomheder til at opfylde deres databeskyttelseskrav både interne og lovgivningsmæssige.

Nu er vi på et sted, hvor vi kan komme med en fornuftig anbefaling til, hvordan man bygger en (ikke-ikke) NIST-kompatibel Blockchain-baseret virksomhedsapplikation – en blueprint.

Faktiske implementerings- og driftsomkostninger er ikke offentligt tilgængelige, men baseret på forfatterens viden løber mellem otte og pæne tal i USD med driftsomkostninger typisk i intervallet 15 – 25 % – se også nogle referencer link. , link.. Disse omkostningsintervaller er typiske for storskala virksomhedssystemimplementeringer og operationer såsom ERP-systemer.

Med udgangspunkt i FISMA-loven og OMB-cirkulære A-130 er det agenturers ansvar at sikre, at risikoen ved at bruge et informationssystem til at udføre aktiviteter som adgang, overførsel, lagring, behandling af føderale data er blevet fastlagt og accepteret, og at en ATO er blevet godkendt til sådanne systemer.

Som figuren viser, starter vi med en traditionel virksomhedssoftwarestak på toppen – først applikationslaget, derefter applikationsabstraktionslaget og derefter middlewarelaget – med al den nødvendige compliance, f.eks. NIST compliance indbygget. I bunden af ​​stakken har vi en offentlig Blockchain, fordi det fjerner behovet for virksomheder til at bygge komplekse konsortier, bruge en masse penge og give dem mulighed for at bevæge sig meget hurtigere med udviklingen af ​​nye produkter. Mellem middleware og offentlige Blockchain-lag er det "magiske" behandlingslag fokuseret på privatliv og hastighed. Da stakken vil bruge privatlivsbevarende ZKP'er og ikke primært bruge digitale aktiver oprettet på den offentlige Blockchain, er tidligere bekymringer om brugen af ​​offentlige Blockchains pludselig væk. Som op- og ned-pilene til venstre i figuren indikerer, øges staksikkerheden, når vi går fra det øverste lag til bunden, den offentlige Blockchain. Det stik modsatte sker med de tre andre nøglekarakteristika – privatliv, hastighed og kontrol; de øges fra det nederste lag til det øverste lag, hvor en enkelt virksomhed har fuld kontrol over alle data, og kan derfor sikre privatlivets fred og samtidig opretholde høj hastighed/skalerbarhed selv for de mest følsomme data. Det betyder dog ikke, at privatlivets fred, hastighed og kontrol er lav mod bunden af ​​stakken, det betyder blot, at den er højere i de øverste lag af stakken end i bunden.

Hvad med det "magiske" behandlingslag/netværk?

Her er, hvad dette lag kan gøre ved at bruge eksisterende teknologi til at opfylde virksomhedens krav:

• Datasikkerhed
  • Zero-Knowledge Bevis for transaktioner
  • Stærk kryptering (hvor påkrævet)
  • Seneste kryptografiteknikker f.eks. kvantesikre algoritmer
• Sikkerhed
  • Arver sikkerhedsgarantierne fra den offentlige Blockchain ved brug af de rigtige ZKP'er forankret på Blockchain
  • Digitale aktivdata kan være direkte tilgængelige via ZKP'er på den offentlige Blockchain for at blive brugt, hvis det kræves
• verificerbarhed
  • Enhver kan verificere beviser på den offentlige Blockchain
  • Beviser kan rekursivt verificere alle aktivtransaktioner og hele aktivtransaktionshistorikken
  • Intet er afsluttet, før beviser er verificeret på den offentlige Blockchain
• Speed
  • Parallelisering af transaktioner
  • Oprulning af transaktioner ved at samle dem med (rekursive) beviser
  • Mindre omkostninger pr. transaktion

Sammenfattende har det "magiske" behandlingslag

• de samme sikkerhedsgarantier som den offentlige Blockchain brugte,
• 100 – 1000 gange mere skalerbarhed,
• garanteret datatilgængelighed,
• privatlivets fred bevares til enhver tid,
• meget lavere transaktionsgebyrer,
• verificerbarhed af alle beviser af enhver på den offentlige Blockchain
• giver mulighed for KYC og AML

Det lyder for godt til at være sandt. Findes en sådan teknologi allerede? Svaret er ja, og virksomheder som Starkware, Aztec, zkSync og andre arbejder på at få deres ZK-Rollup "Layer 2" teknologier fuldt virksomhedsparate. Fokus for alle disse bestræbelser er offentlige Ethereum, fordi det tilbyder de højeste sikkerhedsgarantier (antal minearbejdere/validatorer og total-value-locked (TVL)), kombineret med den nødvendige kryptografiske support indbygget i dets eksekveringslag.

Naturligvis er dette ikke den eneste mulige tilgang for en Blockchain-baseret applikation til at opnå en statslig ATO. Det er dog en ret ligetil og efterhånden velforstået tilgang.

Så hvad er net-nettet her?

Virksomhederne har nu

• A rammer at vurdere use case-behov kontra Blockchain-karakteristika, og hvordan disse behov kan opfyldes af Blockchain-baserede virksomhedsapplikationer, der kan opnå en statslig ATO.
• A blueprint at bygge Blockchain-baserede virksomhedsapplikationer på en måde, der giver dem mulighed for at opnå en statslig ATO, mens de, som afbildet i figuren ovenfor, også giver mulighed for yderligere fordele:
  • Højere tillid gennem offentlige Blockchains, offentlig verificerbarhed og kryptografi håndhævet privatlivets fred
  • Lavere omkostninger gennem nemmere revision (bekræftelse af ZKP'er er hurtig og billig) og fancy transaktionsbatching (oprulninger) i Layer 2-applikationen
  • Hurtigere behandling gennem parallelisering af compute, flere transaktioner gennem rollups og et mindre Blockchain-fodaftryk, da offentlige Blockchains formodes at være langsomme af design for at give mere sikkerhed
  • Mere fleksibilitet og valgmuligheder gennem evnen til at have traditionelle aktiver til at understøtte kryptoaktiver på Blockchain, enklere integration mellem Layer 2 og en offentlig Blockchain og nem udvidelse af lag 2-aktiver til f.eks. de eksisterende DeFi-økosystemer

Afslutningsvis er det vigtigt at bemærke, at i eksemplet med den amerikanske regering er opnåelse af en ATO for et informationssystem ikke kun begrænset til kryptografiske artefakter og kryptomoduler. Disse repræsenterer en vigtig del af de sikkerhedskontroller, der identificeres under risikostyringsprocessen, der er nødvendig for at opnå en ATO, som angivet og forklaret i detaljer i NIST SP 800-37 Rev 2 og NIST FIPS-199. Processen omfatter også elementer såsom brugergodkendelse/godkendelse under forskellige brugsscenarier, kontrol af system- og procesændringer, katastrofegendannelse og forretningskontinuitet.

Er ATO/NIST-overholdelse for Blockchain-applikationer relevant for din virksomhed? EEA ATO-arbejdsgruppen vil gerne have dit input. Venligst kontakt .

Følg os på Twitter, LinkedIn , Facebook at holde sig opdateret om alt, hvad EØS angår.