Opinione: Enterprise Blockchains Redux: come non essere conformi al NIST senza spendere una fortuna PlatoBlockchain Data Intelligence. Ricerca verticale. Ai.

Opinione: Enterprise Blockchains Redux: come non essere conformi al NIST senza spendere troppo

Opinione di Andreas Freund, membro del gruppo di interesse Mainnet dell'EEA

Le blockchain hanno un problema di cui si parla raramente che è indipendente dagli alti e bassi dei mercati crittografici e che può ostacolare l'adozione di Blockchain a lungo termine al di fuori del direct-to-consumer e alcuni casi d'uso B2B: gli algoritmi crittografici Blockchain non sono conformi al NIST, il che è un fattore importante per il raggiungimento della conformità con FISMA (Federal Information Security Management Act)! E la conformità NIST/FISMA, o il suo equivalente al di fuori degli Stati Uniti, è una cosa importante quando le imprese trattano con i governi o le imprese che trattano regolarmente con le imprese che trattano con i governi.

Perché le Blockchain in genere non sono conformi al NIST? Bene, il motivo principale è che le Blockchain sono nate dalla profonda sfiducia nei confronti di qualsiasi cosa gestita dal governo e approvata sulla scia della Grande Recessione del 2008; compresi gli algoritmi crittografici approvati dal governo. In ogni caso, l'algoritmo di hashing SHA-3 ampiamente accettato oggi non è stato finalizzato fino al 2015 dopo che Blockchain come Ethereum avevano già fatto le loro scelte sugli algoritmi di hashing. Pertanto, la maggior parte delle Blockchain come Ethereum utilizza algoritmi che non solo non sono approvati dal NIST, ma che il NIST consiglia di non utilizzare. Nota, ci sono Blockchain conformi a NIST come Simba-Chain o Fabric che operano su LinuxONE di IBM. Tuttavia, sono costose e difficili da gestire in produzione,  come hanno appreso le imprese dopo aver speso alcune decine di milioni di dollari in spese di consulenza e implementazione. Ad aggravare il problema dei costi è che spesso non producono i risultati aziendali attesi perché i casi d'uso scelti non erano adatti per Blockchain per cominciare! Il punto principale della discussione che segue è che qualsiasi nuovo approccio Enterprise Blockchain deve affrontare non solo la conformità NIST, ma anche la complessità dei costi e della gestione in modo efficace per attrarre nuovi sponsor commerciali.

Ciò significa che tutto è senza speranza per Blockchain in un'azienda quando la conformità NIST, i costi e la complessità di gestione sono una preoccupazione?

Fortunatamente, la risposta è no, non è senza speranza. Non banale, ma non senza speranza.

Per capire cosa significa, ricapitoliamo quali sono le caratteristiche delle applicazioni basate su Blockchain può avere:

  • Integrità dei dati: Se hai solo bisogno di quello, allora non usare una Blockchain. Ci sono alternative più economiche.
  • Timestamp dimostrabile: Molto più interessante e utile per gli audit trail, ad esempio lungo le catene di approvvigionamento.
  • Nessun singolo punto di errore: Se hai bisogno del 100% di disponibilità, a un prezzo basso.
  • Resistenza alla censura: accesso a dati che, ad esempio, devono essere verificati da terze parti non necessariamente identificate al momento della creazione dei dati o esecuzione di transazioni (sostanzialmente) irreversibili indipendenti da terze parti.
  • Protezione dalla doppia spesa: Rilevante solo se hai a che fare con risorse digitali su una Blockchain. In altre parole, ti piace davvero la DeFi.
  • Ereditare le garanzie di sicurezza Blockchain: Quello è molto interessante, se hai bisogno di scalabilità dell'applicazione, ma alta sicurezza. Ci arriveremo tra un po'.

Si noti che nessuno dei precedenti parla di privacy dei dati, uno dei gioielli inestimabili dei requisiti delle applicazioni aziendali. Ma non preoccuparti, puoi ottenere la privacy dei dati senza nascondere i dati aziendali sensibili ovunque allo scoperto. Ci arriveremo anche a questo tra un po'.

Prima di andare avanti con noi stessi, fermiamoci qui e discutiamo di come queste caratteristiche si relazionano alla conformità NIST. A prima vista, non così tanto, ma esaminiamo ciascuna caratteristica e discutiamo le sue implicazioni in modo un po' più dettagliato. In primo luogo, tuttavia, vale la pena ricordare che per ottenere i permessi Authority-To-Operate (ATO) da un governo, ad esempio il governo degli Stati Uniti,, è consentito utilizzare algoritmi crittografici non conformi al NIST o algoritmi sui quali il NIST non si è formato un'opinione, purché tali algoritmi non siano fondamentali per la sicurezza dell'applicazione e la riservatezza dei suoi dati. Ad esempio, è necessario dimostrare che un contratto è stato eseguito in un giorno specifico e da allora non è stato modificato. Utilizzando una Blockchain, si formerebbe un'impronta digitale crittografica utilizzando un hash crittografico (approvato dal NIST) del contratto, e quindi si ancorerebbe quell'hash su una Blockchain (pubblica) che fornisce, una volta inclusa in un blocco, un timestamp dimostrabile attraverso la combinazione di numero di blocco, hash del blocco e timestamp. Se la Blockchain fosse riorganizzata, ad esempio attraverso un attacco del 51%, sarebbe ancora possibile prendere la transazione con l'hash del contratto, e il suo blocco e includerli entrambi in un'altra Blockchain (pubblica). Pertanto, la sicurezza della Blockchain originale (pubblica) non è fondamentale per il caso d'uso.

Con questo in mente, esaminiamo nuovamente ciascuna caratteristica, concentrandoci sul suo impatto sulla conformità NIST di un'applicazione che utilizza la tecnologia Blockchain:

  • Integrità dei dati: Questo è facile poiché puoi sempre avere una copia dei dati rilevanti che hai ancorato, ad esempio tramite un hash crittografico sulla Blockchain con un'altra forma di protezione dell'integrità dei dati come una credenziale verificabile W3C a prova di manomissione con un algoritmo di firma crittografica approvato dal NIST .
  • Timestamp dimostrabile: Un po' più difficile ma fattibile. Se la catena utilizzata fosse compromessa, si potrebbe comunque afferrare il blocco con la relativa transazione contenente, ad esempio, un hash crittografico conforme a NIST di un documento e il suo timestamp, e ancorare l'intero blocco con la transazione tramite un altro hash crittografico conforme a NIST su un'altra Blockchain; nessun vero danno fatto.
  • Nessun singolo punto di errore: Ok, quindi questo è un po' complicato poiché il NIST non ha formulato raccomandazioni sugli algoritmi di consenso. Ciò significa che fintanto che il modello di consenso ha una solida base accademica, ad esempio una prova matematica di sicurezza, può essere discusso con successo e lo mettiamo nel secchio non conforme al NIST.
  • Resistenza alla censura: Sembra facile ma poiché significa che i dati saranno prontamente visibili a (quasi) tutti i partecipanti, è necessario prestare molta attenzione nell'usare i giusti metodi di offuscamento per i dati inseriti in una Blockchain, per sostenere con successo che la privacy dei dati viene mantenuta . Quindi quello è un po 'complicato ma può essere superato. Tieniti forte, arrivo subito.
  • Protezione dalla doppia spesa: Ora questo è davvero difficile perché combina i punti precedenti con l'esecuzione deterministica della transazione, la convalida della transazione e la formazione del blocco che si basano tutti in modo complesso sugli algoritmi crittografici utilizzati. Senza entrare nei dettagli, se hai bisogno di una protezione a doppia spesa come caratteristica chiave nella tua applicazione basata su Blockchain, sei sfortunato per quanto riguarda la conformità NIST... se la tua risorsa digitale è nata sulla Blockchain! Torneremo anche su questo punto tra un secondo.
  • Ereditare le garanzie di sicurezza Blockchain: Questo sembra essere chiaro. Se la tua sicurezza si basa in modo critico sulla sicurezza della Blockchain sottostante e quella Blockchain fa affidamento per la sua sicurezza su algoritmi non conformi al NIST; fine della storia. Di nuovo, non così in fretta. La domanda è garanzie di sicurezza per cosa? Se è per gli asset digitali nati su una Blockchain, allora la risposta è la stessa della protezione Double-Spend. Ma, se le risorse digitali vengono create prima dalla Blockchain e solo successivamente replicate sulla Blockchain, la sicurezza di tale risorsa digitale non è più fondamentalmente legata alla Blockchain sottostante e abbiamo lo stesso argomento per il timestamp dimostrabile per tirarci fuori dall'enigma del NIST!

La valutazione d'impatto di cui sopra può ora fungere da elenco di controllo rispetto alle esigenze di conformità NIST di un'applicazione Blockchain, dati i requisiti specifici del caso d'uso di tale applicazione.

Prima di andare avanti e fornire un progetto applicativo per un'applicazione basata su Blockchain non conforme al NIST, parliamo di privacy dei dati. Dati i criteri di cui sopra e le normative sulla privacy dei dati esistenti, mettere anche i dati crittografati su una Blockchain si qualifica come un'idea stupida, anche quando si utilizzano algoritmi di crittografia conformi al NIST. Quindi qual è l'alternativa?

Risposta: prove a conoscenza zero (ZKP)

Le ZKP riguardano il rilascio di dichiarazioni senza rivelare dati sensibili sottostanti, ad esempio il saldo del conto della società ACME è superiore a $ 100,000 o questo codice sconto è stato correttamente applicato a questo ordine.

Esistono molti tipi di ZKP utili: Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs e così via. La chiave è utilizzare algoritmi crittografici conformi a NIST o non conformi a NIST quando si utilizzano ZKP. Altrimenti, fallo! Le ZKP sono un ottimo strumento per le aziende per soddisfare i requisiti di privacy dei dati sia interni che normativi.

Ora siamo in grado di formulare una raccomandazione sensata su come costruire un'applicazione aziendale basata su Blockchain (non-non) conforme al NIST: un progetto.

I costi effettivi di distribuzione e operativi non sono disponibili al pubblico ma, in base alle conoscenze degli autori, oscillano tra otto e cifre interessanti in USD con costi operativi tipicamente compresi tra il 15 e il 25% – vedere anche alcuni riferimenti qui ed qui. Queste fasce di costo sono tipiche delle implementazioni e delle operazioni di sistemi aziendali su larga scala come i sistemi ERP.

Secondo la legge FISMA e la circolare OMB A-130, spetta alle agenzie garantire che il rischio derivante dall'utilizzo di un sistema informativo per eseguire attività come l'accesso, il trasferimento, l'archiviazione, l'elaborazione dei dati federali sia stato determinato e accettato e che un ATO è stato approvato per tali sistemi.

Come mostra la figura, iniziamo con uno stack software aziendale tradizionale in alto – prima il livello dell'applicazione, poi il livello di astrazione dell'applicazione e infine il livello del middleware – con tutta la conformità richiesta, ad esempio la conformità NIST integrata. In fondo alla pila, abbiamo una Blockchain pubblica perché elimina la necessità per le imprese di creare consorzi complessi, spendere molti soldi e consentire loro di muoversi molto più rapidamente con lo sviluppo di nuovi prodotti. Tra il middleware e il livello Blockchain pubblico, c'è il livello di elaborazione "magico" incentrato su privacy e velocità. Poiché lo stack utilizzerà ZKP che preservano la privacy e non utilizzerà principalmente risorse digitali create sulla Blockchain pubblica, le precedenti preoccupazioni sull'utilizzo delle Blockchain pubbliche sono improvvisamente svanite. Come indicano le frecce su e giù a sinistra della figura, la sicurezza dello stack aumenta man mano che si passa dal livello superiore a quello inferiore, la Blockchain pubblica. L'esatto contrario accade con le altre tre caratteristiche chiave: privacy, velocità e controllo; aumentano dal livello inferiore al livello superiore dove una singola azienda ha il pieno controllo di tutti i dati, e può quindi garantire la privacy mantenendo alta velocità/scalabilità anche per i dati più sensibili. Ciò non significa, tuttavia, che la privacy, la velocità e il controllo siano bassi verso la parte inferiore dello stack, significa solo che sono più elevati negli strati superiori dello stack rispetto a quelli inferiori.

Ora, che dire di quel livello/rete di elaborazione "magico"?

Ecco cosa può fare quel livello utilizzando la tecnologia esistente per soddisfare i requisiti aziendali:

  • Privacy dei dati
    • Prove di transazioni a conoscenza zero
    • Crittografia forte (dove richiesto)
    • Tecniche di crittografia più recenti, ad esempio algoritmi di sicurezza quantistica
  • Sicurezza
    • Eredita le garanzie di sicurezza dalla Blockchain pubblica quando si utilizzano le giuste ZKP ancorate alla Blockchain
    • I dati delle risorse digitali possono essere direttamente disponibili tramite ZKP sulla Blockchain pubblica da utilizzare se necessario
  • verificabilità
    • Chiunque può verificare le prove sulla Blockchain pubblica
    • Le prove possono verificare in modo ricorsivo tutte le transazioni di asset e l'intera cronologia delle transazioni di asset
    • Nulla è finalizzato finché le prove non vengono verificate sulla Blockchain pubblica
  • Velocità
    • Parallelizzazione delle transazioni
    • Arrotolare le transazioni raggruppandole con prove (ricorsive).
    • Minor costo per transazione

In sintesi, il livello di elaborazione "magico" ha

  • le stesse garanzie di sicurezza della Blockchain pubblica utilizzata,
  • 100 – 1000 volte più scalabilità,
  • disponibilità dei dati garantita,
  • privacy preservata in ogni momento,
  • commissioni di transazione molto più basse,
  • verificabilità di tutte le prove da parte di chiunque sulla Blockchain pubblica
  • consente KYC e AML

Sembra troppo bello per essere vero. Tale tecnologia esiste già? La risposta è sì e aziende come Starkware, Aztec, zkSync e altre stanno lavorando per rendere le loro tecnologie ZK-Rollup "Layer 2" completamente pronte per l'azienda. L'obiettivo di tutti questi sforzi è Ethereum pubblico perché offre le più alte garanzie di sicurezza (numero di minatori/validatori e valore totale bloccato (TVL)), combinato con il supporto crittografico richiesto integrato nel suo livello di esecuzione.

Naturalmente, questo non è l'unico approccio possibile per un'applicazione basata su Blockchain per ottenere un'ATO governativa. Tuttavia, è un approccio abbastanza semplice e ormai ben compreso.

Allora qual è la rete-rete qui?

Le imprese ora hanno

  • A contesto per valutare le esigenze dei casi d'uso rispetto alle caratteristiche di Blockchain e come queste esigenze possono essere soddisfatte dalle applicazioni aziendali basate su Blockchain che possono ottenere un ATO governativo.
  • A cianografia costruire applicazioni aziendali basate su Blockchain in modo da consentire loro di ottenere un'ATO governativa mentre, come illustrato nella figura sopra, consente anche ulteriori vantaggi:
    • Maggiore fiducia attraverso Blockchain pubbliche, verificabilità pubblica e privacy imposta dalla crittografia
    • Costo più basso attraverso una verificabilità più semplice (la verifica delle ZKP è rapida ed economica) e un sofisticato raggruppamento delle transazioni (rollup) nell'applicazione di livello 2
    • Elaborazione più veloce attraverso la parallelizzazione del calcolo, più transazioni tramite rollup e un'impronta Blockchain più piccola poiché si suppone che le Blockchain pubbliche siano lente per progettazione per fornire maggiore sicurezza
    • Più flessibilità e scelta attraverso la possibilità di disporre di risorse tradizionali per sostenere le risorse crittografiche sulla Blockchain, un'integrazione più semplice tra Layer 2 e una Blockchain pubblica e una facile estensione delle risorse di livello 2, ad esempio, negli ecosistemi DeFi esistenti

In chiusura, è importante notare che nell'esempio del governo degli Stati Uniti, l'ottenimento di un'ATO per un sistema informativo non si limita solo agli artefatti crittografici e ai moduli crittografici. Questi rappresentano una parte importante dei controlli di sicurezza che vengono identificati durante il processo di gestione del rischio necessario per ottenere un'ATO, come elencato e spiegato in dettaglio in NIST SP 800-37 Rev 2 e NIST FIPS-199. Il processo include anche elementi come l'autenticazione/autorizzazione dell'utente in diversi scenari di utilizzo, controlli di modifica del sistema e del processo, ripristino di emergenza e continuità aziendale.

La conformità ATO/NIST per le applicazioni Blockchain è rilevante per la tua azienda? Il gruppo di lavoro AEA ATO vorrebbe il vostro contributo. Si prega di contattare .

Seguici su TwitterLinkedIn ed Facebook per rimanere aggiornato su tutto ciò che riguarda il SEE.

Timestamp:

Di più da Enterprise Ethereum Alliance