Åsikt: Enterprise Blockchains Redux: Hur man inte är NIST-kompatibel utan att bryta banken

Yttrande från Andreas Freund, EES Mainnet Intressegruppmedlem

Blockkedjor har ett sällan omtalat problem som är oberoende av krypteringsmarknadernas upp- och nedgångar, och som kan hämma blockchain-antagande på längre sikt utanför direkt till konsument och vissa B2B-användningsfall: Blockchains kryptografiska algoritmer är inte NIST-kompatibla, vilket är en viktig faktor för att uppnå överensstämmelse med FISMA (Federal Information Security Management Act)! Och efterlevnad av NIST/FISMA, eller motsvarande utanför USA, är en stor sak när företag har att göra med regeringar eller företag som regelbundet har att göra med företag som har att göra med regeringar.

Varför är blockkedjor vanligtvis inte NIST-kompatibla? Tja, den främsta anledningen är att blockkedjor föddes ur den djupa misstroendet mot allt som drivs av regeringen och godkändes i kölvattnet av den stora lågkonjunkturen 2008; inklusive statligt godkända kryptografiska algoritmer. Hur som helst, SHA-3-hashalgoritmen som är allmänt accepterad idag slutfördes inte förrän 2015 efter att blockkedjor som Ethereum redan hade gjort sina val om hashalgoritmer. Därför använder de flesta blockkedjor som Ethereum algoritmer som inte bara inte är NIST-godkända, utan som NIST rekommenderar att inte använda. Observera att det finns NIST-kompatibla blockkedjor som Simba-Chain eller Fabric som fungerar på IBMs LinuxONE. De är dock höga och svåra att hantera i produktionen[1]  som företag lärde sig efter att ha spenderat några tiotals miljoner dollar på konsult- och implementeringsavgifter. Förvärrar kostnadsproblemet är att de ofta inte ger de förväntade affärsresultaten eftersom de valda användningsfallen inte var lämpade för blockkedjor till att börja med! Det viktigaste för diskussionen nedan är att varje ny Enterprise Blockchain-strategi inte bara måste ta itu med NIST-efterlevnad utan också både kostnads- och hanteringskomplexitet för att attrahera nya företagssponsorer.

Betyder det att allt är hopplöst för Blockchain i ett företag när NIST-efterlevnad, kostnad och hanteringskomplexitet är ett problem?

Lyckligtvis är svaret nej, det är inte hopplöst. Inte trivialt, men inte hopplöst.

För att förstå vad detta betyder, låt oss sammanfatta vilka egenskaper Blockchain-baserade applikationer Kan ha:

• Dataintegritet: Om du bara behöver det, använd då inte en Blockchain. Det finns billigare alternativ.
• Bevisbar tidsstämpling: Mycket mer intressant och användbar för revisionsspår, t.ex. över leverantörskedjor.
• Ingen single-point-of-failure: Om du behöver 100 % tillgänglighet, till ett lågt pris.
• Censurmotstånd: Tillgång till data som till exempel behöver granskas av tredje part som inte nödvändigtvis identifieras vid tidpunkten för dataskapande, eller utför (i princip) irreversibla transaktioner oberoende av någon tredje part.
• Skydd med dubbla utgifter: Endast relevant om du har att göra med digitala tillgångar på en Blockchain. Med andra ord, du gillar verkligen DeFi.
• Ärver Blockchain-säkerhetsgarantier: Den här är väldigt intressant, om du behöver applikationsskalbarhet, men ändå hög säkerhet. Vi kommer till det om ett tag.

Observera att inget av ovanstående talar om datasekretess, en av de ovärderliga juvelerna i företagsapplikationskrav. Men inga bekymmer, du kan uppnå datasekretess utan att plasta in företagskänsliga data överallt i det fria. Vi kommer till det om ett tag också.

Innan vi går före oss själva, låt oss pausa här och diskutera hur dessa egenskaper relaterar till NIST-efterlevnad. Vid första anblicken, inte så mycket, men låt oss gå igenom varje egenskap och diskutera dess implikationer lite mer detaljerat. Först är det dock värt att nämna att för att erhålla Authority-To-Operate (ATO)-tillstånd från en regering, t.ex. den amerikanska regeringen[2], är det ok att använda icke-NIST-kompatibla kryptografiska algoritmer, eller algoritmer som NIST inte har bildat sig en uppfattning om, så länge dessa algoritmer inte är grundläggande för applikationens säkerhet och integriteten för dess data. Du måste till exempel bevisa att ett kontrakt tecknades en viss dag och inte har ändrats sedan dess. Med hjälp av en Blockchain skulle man bilda ett kryptografiskt fingeravtryck med en (NIST-godkänd) kryptografisk hash av kontraktet, och sedan förankra denna hash på en (offentlig) Blockchain som ger, när den väl ingår i ett block, en bevisbar tidsstämpel genom kombinationen av blocknummer, blockhash och tidsstämpel. Om blockkedjan omorganiserades, till exempel genom en 51%-attack, skulle det fortfarande vara möjligt att ta transaktionen med kontraktshashen och dess blockering och inkludera båda i en annan (offentlig) blockkedja. Därför är säkerheten för den ursprungliga (offentliga) Blockchain inte grundläggande för användningsfallet.

Med detta i åtanke, låt oss titta igen på varje egenskap, med fokus på dess inverkan på NIST-efterlevnad av en applikation som använder Blockchain-teknik:

• Dataintegritet: Den här är enkel eftersom du alltid kan ha en kopia av den relevanta data som du förankrat t.ex. via en kryptografisk hash på Blockchain med en annan form av dataintegritetsskydd såsom en manipuleringssäker W3C Verifiable Credential med en NIST-godkänd kryptografisk signaturalgoritm .
• Bevisbar tidsstämpling: Lite svårare men genomförbart. Om den använda kedjan äventyras, kan man fortfarande ta blocket med den relevanta transaktionen innehållande t.ex. en NIST-kompatibel kryptografisk hash av ett dokument, och dess tidsstämpel, och förankra hela blocket med transaktionen genom en annan NIST-kompatibel kryptografisk hash på en annan Blockchain; ingen verklig skada skedd.
• Ingen single-point-of-failure: Ok, så det här är lite knepigt eftersom NIST inte har utformat rekommendationer om konsensusalgoritmer. Det betyder att så länge som konsensusmodellen har en solid akademisk grund, t.ex. ett matematiskt bevis på säkerhet, kan den framgångsrikt argumenteras för, och vi lägger den i den inte-inte-NIST-kompatibla hinken.
• Censurmotstånd: Det här låter som en lätt men eftersom det betyder att data kommer att vara lätt synliga för (nästan) alla deltagare, måste stor noggrannhet tas för att använda rätt fördunklingsmetoder för data som läggs på en blockchain, för att framgångsrikt argumentera för att dataintegriteten upprätthålls . Så den där är lite knepig men kan övervinnas. Håll ut, kommer direkt upp.
• Skydd med dubbla utgifter: Nu är den här riktigt svår eftersom den kombinerar de föregående punkterna med deterministisk transaktionsexekvering, transaktionsvalidering och blockbildning som alla bygger på de kryptografiska algoritmerna som används. Utan att gå in på detaljer, om du behöver skydd med dubbla utgifter som en nyckelfunktion i din Blockchain-baserade applikation, har du ingen tur vad gäller NIST-efterlevnad ... om din digitala tillgång föddes på Blockchain! Vi kommer också tillbaka till den punkten om en sekund.
• Ärver Blockchain-säkerhetsgarantier: Det här verkar vara entydigt. Om din säkerhet förlitar sig kritiskt på säkerheten för den underliggande Blockchain, och den Blockchain förlitar sig för sin säkerhet på icke-NIST-kompatibla algoritmer; slutet på historien. Återigen, inte så snabbt. Frågan är säkerhetsgarantier för vad? Om det är för digitala tillgångar födda på en Blockchain, så är svaret detsamma som för Double-Spend-skydd. Men om de digitala tillgångarna skapas från Blockchain först, och först sedan replikeras till Blockchain, är säkerheten för den digitala tillgången inte längre fundamentalt knuten till den underliggande Blockchain, och vi har samma argument som för bevisbar tidsstämpling att vicka oss ur NIST-gåtan!

Ovanstående konsekvensbedömning kan nu fungera som en checklista mot en Blockchain-applikations NIST-efterlevnadsbehov, givet de specifika användningsfallskraven för den applikationen.

Innan vi går vidare och ger en applikationsritning för en blockchain-baserad applikation som inte är NIST-kompatibel, låt oss prata om datasekretess. Med tanke på ovanstående kriterier, och befintliga dataskyddsbestämmelser, kvalificerar det att lägga till och med krypterad data på en Blockchain som en dum idé, även när du använder NIST-kompatibla krypteringsalgoritmer. Så vad är alternativet?

Svar: Zero-Knowledge Proofs (ZKPs)

ZKPs handlar om att göra uttalanden utan att avslöja underliggande känsliga data, t.ex. ACME Corporations kontosaldo är över $100,000 XNUMX, eller så användes denna rabattkod korrekt på denna beställning.

Det finns många typer av användbara ZKPs - Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, och så vidare. Nyckeln är att använda antingen NIST-kompatibla eller icke-NIST-kompatibla kryptografiska algoritmer när du använder ZKPs. Annars, kör på! ZKP:er är ett utmärkt verktyg för företag att uppfylla sina datasekretesskrav både interna och regulatoriska.

Nu är vi på ett ställe där vi kan ge en vettig rekommendation om hur man bygger en (inte-inte) NIST-kompatibel Blockchain-baserad företagsapplikation – en ritning.

Faktiska driftsättnings- och driftskostnader är inte allmänt tillgängliga, men baserat på författarnas kunskap ligger mellan åtta och fina siffror i USD med driftskostnader vanligtvis i intervallet 15 – 25 % – se även några referenser här. och här.. Dessa kostnadsintervall är typiska för storskaliga företagssystemimplementeringar och operationer som ERP-system.

Med utgångspunkt från FISMA Act och OMB-cirkulär A-130, är ​​det myndigheters ansvar att säkerställa att risken med att använda ett informationssystem för att utföra aktiviteter som åtkomst, överföring, lagring, bearbetning av federal data har fastställts och accepterats och att en ATO har godkänts för sådana system.

Som bilden visar, börjar vi med en traditionell företagsmjukvarustapel på toppen – först applikationslagret, sedan applikationsabstraktionslagret och sedan mellanvarulagret – med all nödvändig efterlevnad, t.ex. NIST-kompatibilitet inbyggd. Längst ner i stacken har vi en offentlig blockkedja eftersom det undviker behovet för företag att bygga komplexa konsortier, spendera mycket pengar och låta dem röra sig mycket snabbare med utvecklingen av nya produkter. Mellan mellanprogramvaran och det offentliga blockkedjeskiktet finns det "magiska" bearbetningsskiktet fokuserat på integritet och hastighet. Eftersom stacken kommer att använda integritetsbevarande ZKP:er och inte i första hand använda digitala tillgångar som skapats på den offentliga blockkedjan, är tidigare oro över användningen av offentliga blockkedjor plötsligt borta. Som upp- och nedpilarna till vänster i figuren indikerar, ökar stacksäkerheten när vi går från det översta lagret till det nedre, den offentliga Blockchain. Exakt motsatsen händer med de andra tre nyckelegenskaperna – integritet, hastighet och kontroll; de ökar från det nedre lagret till det översta lagret där ett enda företag har full kontroll över all data, och kan därför säkerställa integritet samtidigt som hög hastighet/skalbarhet bibehålls även för de mest känsliga data. Det betyder dock inte att integriteten, hastigheten och kontrollen är låg mot botten av stacken, det betyder bara att den är högre i de översta lagren av stacken än i botten.

Hur är det nu med det "magiska" bearbetningsskiktet/nätverket?

Här är vad det lagret kan göra med hjälp av befintlig teknik för att möta företagskrav:

• Dataintegritet
  • Zero-Knowledge Bevis för transaktioner
  • Stark kryptering (vid behov)
  • Senaste kryptografitekniker t.ex. kvantsäkra algoritmer
• Säkerhet
  • Ärver säkerhetsgarantierna från den offentliga blockkedjan när man använder rätt ZKP:er förankrade på blockkedjan
  • Digital tillgångsdata kan vara direkt tillgänglig via ZKPs på den offentliga blockkedjan för att användas vid behov
• kontrollerbarhet
  • Vem som helst kan verifiera bevis på den offentliga Blockchain
  • Bevis kan rekursivt verifiera alla tillgångstransaktioner och hela tillgångstransaktionshistoriken
  • Ingenting är klart förrän bevis har verifierats på den offentliga blockkedjan
• Fart
  • Parallellisering av transaktioner
  • Rulla upp transaktioner genom att gruppera dem med (rekursiva) bevis
  • Mindre kostnad per transaktion

Sammanfattningsvis har det "magiska" bearbetningsskiktet

• samma säkerhetsgarantier som den offentliga blockkedjan använde,
• 100 – 1000 gånger mer skalbarhet,
• garanterad datatillgänglighet,
• integritet bevaras hela tiden,
• mycket lägre transaktionsavgifter,
• verifierbarhet av alla bevis av vem som helst på den offentliga Blockchain
• tillåter KYC och AML

Det här låter för bra för att vara sant. Finns sådan teknik redan? Svaret är ja, och företag som Starkware, Aztec, zkSync och andra arbetar på att få sin ZK-Rollup "Layer 2"-teknologi helt företagsklar. Fokus för alla dessa ansträngningar är offentliga Ethereum eftersom det erbjuder de högsta säkerhetsgarantierna (antal gruvarbetare/validerare och total-value-locked (TVL)), kombinerat med det erforderliga kryptografiska stödet inbyggt i dess exekveringslager.

Naturligtvis är detta inte det enda möjliga tillvägagångssättet för en Blockchain-baserad applikation för att få en statlig ATO. Det är dock ett ganska okomplicerat och vid det här laget välförstått tillvägagångssätt.

Så vad är nätnätet här?

Företagen har nu

• A ramverk för att bedöma användningsfallsbehov kontra Blockchain-egenskaper, och hur dessa behov kan tillgodoses av Blockchain-baserade företagsapplikationer som kan få en statlig ATO.
• A blueprint att bygga blockkedjebaserade företagsapplikationer på ett sätt som gör det möjligt för dem att erhålla en statlig ATO samtidigt som det, som visas i figuren ovan, också möjliggör ytterligare fördelar:
  • Högre tillit genom offentliga blockkedjor, offentlig verifierbarhet och kryptografi framtvingad integritet
  • Lägre kostnad genom enklare granskningsbarhet (att verifiera ZKPs är snabbt och billigt) och snygg transaktionsbatchning (sammanslagningar) i Layer 2-applikationen
  • Snabbare bearbetning genom parallellisering av beräkningar, fler transaktioner genom sammanslagningar och ett mindre blockkedjeavtryck eftersom offentliga blockkedjor är tänkta att vara långsamma till sin design för att ge mer säkerhet
  • Mer flexibilitet och valmöjligheter genom möjligheten att ha traditionella tillgångar för att stödja kryptotillgångar på Blockchain, enklare integration mellan Layer 2 och en offentlig Blockchain, och enkel utvidgning av lager 2-tillgångar till till exempel de befintliga DeFi-ekosystemen

Avslutningsvis är det viktigt att notera att i exemplet med den amerikanska regeringen är att få en ATO för ett informationssystem inte bara begränsat till kryptografiska artefakter och kryptomoduler. Dessa representerar en viktig del av säkerhetskontrollerna som identifieras under riskhanteringsprocessen som krävs för att erhålla en ATO, som listas och förklaras utförligt i NIST SP 800-37 Rev 2 och NIST FIPS-199. Processen inkluderar också element som användarautentisering/auktorisering under olika användningsscenarier, system- och processändringskontroller, katastrofåterställning och affärskontinuitet.

Är ATO/NIST-efterlevnad för Blockchain-applikationer relevant för ditt företag? EEA ATO-arbetsgruppen vill gärna ha era synpunkter. Vänligen kontakta .

Följ oss på Twitter, LinkedIn och Facebook för att hålla dig uppdaterad om allt som rör EES.