Advies: Enterprise Blockchains Redux: hoe u niet-niet NIST-compatibel kunt zijn zonder de bank te breken?

Advies van Andreas Freund, lid van de Mainnet Interest Group van de EER

Blockchains hebben een zelden besproken probleem dat onafhankelijk is van de ups en downs van cryptomarkten, en dat de acceptatie van Blockchain op langere termijn kan belemmeren buiten direct-to-consumer en sommige B2B-gebruiksgevallen: Blockchain-cryptografische algoritmen zijn niet NIST-compatibel, wat een belangrijke factor bij het voldoen aan de FISMA (Federal Information Security Management Act)! En NIST/FISMA-compliance, of het equivalent daarvan buiten de VS, is belangrijk wanneer bedrijven zaken doen met overheden of bedrijven die regelmatig zaken doen met bedrijven die zaken doen met overheden.

Waarom zijn Blockchains doorgaans niet NIST-compatibel? Welnu, de belangrijkste reden is dat Blockchains zijn geboren uit het diepe wantrouwen van alles wat door de overheid wordt beheerd en goedgekeurd in de nasleep van de Grote Recessie van 2008; inclusief door de overheid goedgekeurde cryptografische algoritmen. Hoe dan ook, het SHA-3-hash-algoritme dat tegenwoordig algemeen wordt geaccepteerd, werd pas in 2015 voltooid nadat Blockchains zoals Ethereum al hun keuzes hadden gemaakt over hash-algoritmen. Daarom gebruiken de meeste Blockchains zoals Ethereum algoritmen die niet alleen niet door NIST zijn goedgekeurd, maar die NIST ook aanraadt om niet te gebruiken. Let op, er zijn NIST-compatibele Blockchains zoals Simba-Chain of Fabric die werken op IBM's LinuxONE. Ze zijn echter duur en moeilijk te beheren in productie[1]  zoals ondernemingen leerden na enkele tientallen miljoenen dollars te hebben uitgegeven aan advies- en implementatiekosten. Het kostenprobleem is dat ze vaak niet de verwachte bedrijfsresultaten opleveren omdat de gekozen use-cases om te beginnen niet geschikt waren voor Blockchains! De belangrijkste conclusie voor de onderstaande discussie is dat elke nieuwe Enterprise Blockchain-aanpak niet alleen NIST-compliance moet aanpakken, maar ook zowel de kosten als de beheercomplexiteit effectief moet aanpakken om nieuwe zakelijke sponsors aan te trekken.

Betekent dit dat alles hopeloos is voor Blockchain in een onderneming wanneer NIST-compliance, kosten en beheercomplexiteit een punt van zorg zijn?

Gelukkig is het antwoord nee, het is niet hopeloos. Niet triviaal, maar niet hopeloos.

Laten we, om te begrijpen wat dit betekent, samenvatten welke kenmerken Blockchain-gebaseerde applicaties wel hebben:

• Data-integriteit: Als je alleen dat nodig hebt, gebruik dan geen Blockchain. Er zijn goedkopere alternatieven.
• Bewijsbare tijdstempel: Veel interessanter en nuttiger voor audit trails, bijvoorbeeld over supply chains heen.
• Geen single-point-of-failure: Als u 100% beschikbaarheid nodig heeft, tegen een lage prijs.
• Weerstand tegen censuur: Toegang tot gegevens die bijvoorbeeld moeten worden gecontroleerd door derden die niet noodzakelijkerwijs worden geïdentificeerd op het moment dat de gegevens worden aangemaakt, of die (in principe) onomkeerbare transacties uitvoeren, onafhankelijk van een derde partij.
• Bescherming tegen dubbele uitgaven: Alleen relevant als je te maken hebt met digitale assets op een Blockchain. Met andere woorden, je bent echt dol op DeFi.
• Blockchain-beveiligingsgaranties overnemen: Die is erg interessant, als je schaalbaarheid van applicaties nodig hebt, maar toch een hoge beveiliging. Daar komen we zo dadelijk op.

Merk op dat geen van de bovenstaande zaken gaat over gegevensprivacy, een van de onschatbare juwelen van de vereisten voor bedrijfsapplicaties. Maar geen zorgen, u kunt gegevensprivacy bereiken zonder bedrijfsgevoelige gegevens overal in de openbaarheid te pleisteren. Ook daar komen we zo dadelijk op.

Laten we, voordat we op de zaken vooruit lopen, hier even stilstaan ​​en bespreken hoe deze kenmerken verband houden met NIST-compliance. Op het eerste gezicht niet zo veel, maar laten we elk kenmerk doornemen en de implicaties ervan in wat meer detail bespreken. Ten eerste is het echter vermeldenswaard dat het verkrijgen van Authority-To-Operate (ATO)-machtigingen van een overheid, bijv. de Amerikaanse overheid[2], is het oké om niet-NIST-compatibele cryptografische algoritmen te gebruiken, of algoritmen waarover NIST geen mening heeft gevormd, zolang die algoritmen niet fundamenteel zijn voor de veiligheid van de applicatie en de privacy van de gegevens. U moet bijvoorbeeld aantonen dat een contract op een bepaalde dag is uitgevoerd en sindsdien niet is gewijzigd. Met behulp van een Blockchain zou men een cryptografische vingerafdruk vormen met behulp van een (NIST-goedgekeurde) cryptografische hash van het contract, en die hash vervolgens verankeren op een (openbare) Blockchain die, eenmaal opgenomen in een blok, een aantoonbaar tijdstempel geeft door de combinatie van bloknummer, blokhash en tijdstempel. Als de Blockchain zou worden gereorganiseerd, bijvoorbeeld door een 51%-aanval, zou het nog steeds mogelijk zijn om de transactie met de contracthash en het blok ervan te nemen en beide op te nemen in een andere (openbare) Blockchain. Daarom is de veiligheid van de originele (openbare) Blockchain niet fundamenteel voor de use case.

Laten we met dit in gedachten elk kenmerk opnieuw bekijken, met de nadruk op de impact ervan op NIST-compliance van een applicatie die Blockchain-technologie gebruikt:

• Data-integriteit: Deze is eenvoudig, omdat u altijd een kopie kunt hebben van de relevante gegevens die u hebt verankerd, bijvoorbeeld via een cryptografische hash op de Blockchain met een andere vorm van bescherming van gegevensintegriteit, zoals een fraudebestendige W3C-verifieerbare referentie met een door NIST goedgekeurd algoritme voor cryptografisch handtekeningen .
• Bewijsbare tijdstempel: Iets moeilijker maar te doen. Als de gebruikte keten gecompromitteerd zou zijn, zou men nog steeds het blok kunnen pakken met de relevante transactie die bijvoorbeeld een NIST-compatibele cryptografische hash van een document bevat, en zijn tijdstempel, en het hele blok met de transactie verankeren via een andere NIST-compatibele cryptografische hash op een andere Blockchain; geen echte schade aangericht.
• Geen single-point-of-failure: Ok, dus dit is een beetje lastig aangezien NIST geen aanbevelingen heeft gedaan over consensusalgoritmen. Dat betekent dat zolang het consensusmodel een solide academische basis heeft, bijvoorbeeld een wiskundig bewijs van veiligheid, er met succes voor kan worden gepleit, en we het in de niet-niet-NIST-conforme emmer plaatsen.
• Weerstand tegen censuur: Dit klinkt als een makkelijke maar omdat het betekent dat gegevens direct zichtbaar zijn voor (bijna) alle deelnemers, moet er goed op worden gelet om de juiste verduisteringsmethoden te gebruiken voor gegevens die op een Blockchain worden geplaatst, om met succes te beargumenteren dat de gegevensprivacy wordt gehandhaafd . Dus dat is een beetje lastig, maar kan worden overwonnen. Hou je vast, kom zo naar boven.
• Bescherming tegen dubbele uitgaven: Dit is nu echt moeilijk omdat het de vorige punten combineert met deterministische transactie-uitvoering, transactievalidatie en blokvorming die allemaal ingewikkeld afhankelijk zijn van de gebruikte cryptografische algoritmen. Zonder in details te treden, als je dubbele uitgavenbescherming nodig hebt als een belangrijke functie in je Blockchain-gebaseerde applicatie, heb je pech wat betreft NIST-compliance … als je digitale asset op de Blockchain is geboren! Ook op dat punt komen we zo terug.
• Blockchain-beveiligingsgaranties overnemen: Dit lijkt duidelijk. Als uw beveiliging in hoge mate afhankelijk is van de beveiliging van de onderliggende Blockchain, en die Blockchain voor zijn beveiliging vertrouwt op niet-NIST-compatibele algoritmen; einde van het verhaal. Nogmaals, niet zo snel. De vraag is veiligheidsgaranties voor wat? Als het gaat om digitale activa die zijn geboren op een Blockchain, dan is het antwoord hetzelfde als voor bescherming tegen dubbele uitgaven. Maar als de digitale activa eerst van de Blockchain worden gemaakt en pas daarna naar de Blockchain worden gerepliceerd, is de beveiliging van dat digitale activum niet langer fundamenteel gebonden aan de onderliggende Blockchain en hebben we hetzelfde argument als voor aantoonbare tijdstempels om ons uit het NIST-raadsel te bewegen!

De bovenstaande effectbeoordeling kan nu dienen als een checklist voor de NIST-compliancebehoeften van een Blockchain-applicatie, gezien de specifieke use case-vereisten van die applicatie.

Voordat we verder gaan en een applicatieblauwdruk geven voor een niet-niet-NIST-compatibele Blockchain-gebaseerde applicatie, laten we het hebben over gegevensprivacy. Gezien de bovenstaande criteria en de bestaande regelgeving inzake gegevensprivacy, is het plaatsen van zelfs versleutelde gegevens op een Blockchain een dom idee, zelfs bij gebruik van NIST-compatibele versleutelingsalgoritmen. Dus wat is het alternatief?

Antwoord: Nul-Kennis Bewijzen (ZKP's)

ZKP's gaan over het afleggen van verklaringen zonder onderliggende gevoelige gegevens te onthullen, bijvoorbeeld het rekeningsaldo van ACME Corporation is meer dan $ 100,000, of deze kortingscode is correct toegepast op deze bestelling.

Er zijn veel soorten bruikbare ZKP's - Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, enzovoort. De sleutel is om NIST-compatibele of niet-niet-NIST-compatibele cryptografische algoritmen te gebruiken bij het gebruik van ZKP's. Ga er anders voor! ZKP's zijn een geweldig hulpmiddel voor ondernemingen om te voldoen aan hun vereisten voor gegevensprivacy, zowel intern als wettelijk.

Nu zijn we op een punt om een ​​verstandige aanbeveling te doen voor het bouwen van een (niet-niet) NIST-compatibele Blockchain-gebaseerde bedrijfsapplicatie - een blauwdruk.

Werkelijke implementatie- en bedrijfskosten zijn niet openbaar beschikbaar, maar op basis van de kennis van de auteurs lopen tussen de acht en mooie cijfers in USD met bedrijfskosten meestal in het bereik van 15 - 25% - zie ook enkele referenties hier en hier. Deze kostenbereiken zijn typerend voor grootschalige implementaties en bewerkingen van bedrijfssystemen, zoals ERP-systemen.

Afkomstig uit de FISMA-wet en de OMB-circulaire A-130, is het de verantwoordelijkheid van de agentschappen om ervoor te zorgen dat het risico van het gebruik van een informatiesysteem voor het uitvoeren van activiteiten zoals toegang, overdracht, opslag en verwerking van federale gegevens is vastgesteld en aanvaard en dat een ATO is goedgekeurd voor dergelijke systemen.

Zoals de afbeelding laat zien, beginnen we met een traditionele enterprise-softwarestack bovenaan – eerst de applicatielaag, dan de applicatie-abstractielaag en dan de middlewarelaag – met alle vereiste compliance, bijvoorbeeld NIST-compliance ingebouwd. Aan de onderkant van de stapel hebben we een openbare Blockchain omdat dat de noodzaak voor ondernemingen wegneemt om complexe consortia te bouwen, veel geld uit te geven en hen in staat stelt veel sneller te gaan met de ontwikkeling van nieuwe producten. Tussen de middleware en de openbare Blockchain-laag bevindt zich de "magische" verwerkingslaag gericht op privacy en snelheid. Omdat de stack privacybeschermende ZKP's zal gebruiken en niet primair digitale activa gebruikt die zijn gemaakt op de openbare Blockchain, zijn eerdere zorgen over het gebruik van openbare Blockchains plotseling verdwenen. Zoals de pijlen omhoog en omlaag aan de linkerkant van de afbeelding aangeven, neemt de stapelbeveiliging toe naarmate we van de bovenste laag naar de onderkant gaan, de openbare Blockchain. Precies het tegenovergestelde gebeurt met de andere drie belangrijke kenmerken – privacy, snelheid en controle; ze groeien van de onderste laag naar de bovenste laag waar een enkele onderneming de volledige controle heeft over alle gegevens, en daarom privacy kan garanderen met behoud van hoge snelheid / schaalbaarheid, zelfs voor de meest gevoelige gegevens. Dat betekent echter niet dat privacy, snelheid en controle laag zijn richting de onderkant van de stack, het betekent alleen dat deze hoger is in de bovenste lagen van de stack dan aan de onderkant.

Hoe zit het nu met die "magische" verwerkingslaag / netwerk?

Dit is wat die laag kan doen met behulp van bestaande technologie om aan de bedrijfsvereisten te voldoen:

• Data Privacy
  • Nul-kennisbewijzen van transacties
  • Sterke encryptie (waar vereist)
  • Nieuwste cryptografietechnieken, bijv. kwantumbeveiligde algoritmen
• Security
  • Erft de veiligheidsgaranties van de openbare Blockchain bij gebruik van de juiste ZKP's die op de Blockchain zijn verankerd
  • Digitale activagegevens kunnen direct beschikbaar zijn via ZKP's op de openbare Blockchain om indien nodig te gebruiken
• controleerbaarheid
  • Iedereen kan bewijzen verifiëren op de openbare Blockchain
  • Bewijzen kunnen recursief alle activatransacties en de volledige activatransactiegeschiedenis verifiëren
  • Niets is definitief totdat bewijzen zijn geverifieerd op de openbare Blockchain
• Speed
  • Parallellisatie van transacties
  • Transacties optellen door ze te batchen met (recursieve) bewijzen
  • Minder kosten per transactie

Samenvattend heeft de "magische" verwerkingslaag:

• dezelfde beveiligingsgaranties als de openbare Blockchain,
• 100 – 1000x meer schaalbaarheid,
• gegarandeerde beschikbaarheid van gegevens,
• privacy te allen tijde behouden,
• veel lagere transactiekosten,
• verifieerbaarheid van alle bewijzen door iedereen op de openbare Blockchain
• staat KYC en AML . toe

Dit klinkt te mooi om waar te zijn. Bestaat dergelijke technologie al? Het antwoord is ja, en bedrijven zoals Starkware, Aztec, zkSync en anderen werken eraan om hun ZK-Rollup "Layer 2"-technologieën volledig bedrijfsklaar te maken. De focus voor al deze inspanningen is openbaar Ethereum omdat het de hoogste veiligheidsgaranties biedt (aantal miners/validators en total-value-locked (TVL)), gecombineerd met de vereiste cryptografische ondersteuning ingebouwd in de uitvoeringslaag.

Uiteraard is dit niet de enige mogelijke aanpak voor een Blockchain-gebaseerde applicatie om een ​​ATO van de overheid te verkrijgen. Het is echter een vrij eenvoudige en inmiddels goed begrepen aanpak.

Dus wat is het netto-net hier?

Ondernemingen hebben nu

• A kader om use case-behoeften te beoordelen versus Blockchain-kenmerken, en hoe aan deze behoeften kan worden voldaan door op Blockchain gebaseerde bedrijfsapplicaties die een ATO van de overheid kunnen krijgen.
• A plan om op Blockchain gebaseerde bedrijfsapplicaties te bouwen op een manier die hen in staat zou stellen een ATO van de overheid te verkrijgen, terwijl, zoals weergegeven in de bovenstaande afbeelding, ook extra voordelen mogelijk zijn:
  • Hoger vertrouwen via openbare Blockchains, openbare verifieerbaarheid en door cryptografie afgedwongen privacy
  • Lagere kost door eenvoudigere controleerbaarheid (het verifiëren van ZKP's is snel en goedkoop) en fancy transactiebatches (rollups) in de Layer 2-toepassing
  • Snellere verwerking door parallellisatie van rekenkracht, meer transacties via rollups en een kleinere Blockchain-voetafdruk, aangezien openbare Blockchains van nature traag zouden moeten zijn om meer veiligheid te bieden
  • Meer flexibiliteit en keuze door de mogelijkheid om traditionele activa te hebben om crypto-activa op de Blockchain te ondersteunen, eenvoudigere integratie tussen Layer 2 en een openbare Blockchain en eenvoudige uitbreiding van laag 2-activa naar bijvoorbeeld de bestaande DeFi-ecosystemen

Tot slot is het belangrijk op te merken dat in het voorbeeld van de Amerikaanse overheid het verkrijgen van een ATO voor een informatiesysteem niet alleen beperkt is tot cryptografische artefacten en crypto-modules. Deze vormen een belangrijk onderdeel van de beveiligingscontroles die worden geïdentificeerd tijdens het risicobeheerproces dat nodig is om een ​​ATO te verkrijgen, zoals vermeld en uitgebreid uitgelegd in NIST SP 800-37 Rev 2 en NIST FIPS-199. Het proces omvat ook elementen zoals gebruikersauthenticatie/autorisatie onder verschillende gebruiksscenario's, systeem- en proceswijzigingscontroles, noodherstel en bedrijfscontinuïteit.

Is ATO/NIST-compliance voor Blockchain-applicaties relevant voor uw bedrijf? De EEA ATO-werkgroep wil graag uw input. Neem contact op .

Volg ons op Twitter, LinkedIn en Facebook om op de hoogte te blijven van alles wat met de EER te maken heeft.