#algoritmi hash

[crypto28ro]

Adam Back: Cryptograf și Inventator al Tehnologiei Hashcash – Precursorul Sistemelor Blockchain

Adam Back: Cryptograf și Inventator al Tehnologiei Hashcash – Precursorul Sistemelor Blockchain Adam Back este o figură de referință în domeniul criptografiei, recunoscut la nivel global pentru inovațiile sale, printre care se numără tehnologia Hashcash. Acest sistem, conceput ca un mecanism de combatere a spamului și de asigurare a securității, a devenit un precursor esențial al tehnologiilor…

[vorticimagazine]

Crittografia post quantistica e e geo-politica

Crittografia post quantistica e e geo-politica Questa settimana, ci ha incuriosito un argomento davvero particolare: la crittografia post quantistica. Noi di Vortici.it ci siamo chiesti: di cosa si tratta esattamente? o molto più semplicemente di cosa parliamo? ed ancora cosa c'entra la geopolitica? Per questo motivo vi proponiamo un approfondimento curato da AIDR(Associazione Italian Digital Revolution).  

Crittografia post quantistica tra sicurezza nazionale e geo-politica globale di Davide Maniscalco, Coordinatore regionale Aidr, Legal e Privacy officer Swascan, Tinexta Group Il National Institute of Standards and Technology (NIST) del Dipartimento del Commercio degli Stati Uniti ha scelto il primo gruppo di strumenti di crittografia progettati per resistere all'assalto di un futuro computer quantistico.

Il calcolo quantistico ha infatti una potenza di elaborazione tale da costituire una potenziale minaccia per la violazione delle misure di sicurezza utilizzate a protezione della privacy nei sistemi interconnessi dell’ecosistema digitale e, più in generale, per la sicurezza delle nostre informazioni digitali. Ed invero, i sistemi di crittografia a chiave pubblica attualmente “in campo” utilizzano la matematica per proteggere le informazioni elettroniche sensibili, assicurando che le informazioni digitali siano inaccessibili a terze parti indesiderate.

Tuttavia, un computer quantistico sufficientemente capace, basato su una tecnologia diversa rispetto agli odierni computer convenzionali, può risolvere rapidamente i problemi di matematica posti alla base dei sistemi di crittografia attuali, violandone pertanto la confidenzialità. Per contro, gli algoritmi resistenti ai quanti si basano su problemi matematici (principalmente reticoli strutturati ma anche funzioni di hash) che sia i computer convenzionali che quantistici dovrebbero avere difficoltà a risolvere. Gli algoritmi sono progettati per due compiti principali per i quali viene generalmente utilizzata la crittografia: -crittografia generale, utilizzata per proteggere le informazioni scambiate su una rete pubblica -firme digitali, utilizzate per l'autenticazione dell'identità. L'annuncio del prossimo rilascio di standard crittografici segue uno sforzo di sei anni gestito dal NIST, che nel 2016 ha invitato i crittografi di tutto il mondo a ideare e quindi controllare metodi di crittografia in grado di resistere a un attacco da un futuro computer quantistico. I quattro algoritmi di crittografia selezionati diventeranno così parte dello standard crittografico post-quantistico del NIST, che dovrebbe essere finalizzato in circa due anni. Per la crittografia generale, il NIST ha selezionato l'algoritmo CRYSTALS-Kyber caratterizzato da chiavi di crittografia relativamente piccole che due parti possono scambiare facilmente con maggiore velocità di funzionamento. Per le firme digitali, spesso utilizzate per verificare l'identità durante una transazione digitale o per firmare un documento a distanza, il NIST ha selezionato i tre algoritmi CRYSTALS-Dilithium, FALCON e SPHINCS+. Ma perché l'annuncio del NIST sugli algoritmi crittografici post-quantistici è così importante sul piano tecnologico nel contesto geo-politico? E’ notorio che il governo cinese ha stanziato ben 10 miliardi di dollari per promuovere l'informatica quantistica, aumentando gli investimenti governativi di oltre il 7%. Di contro, il Dipartimento del Commercio USA ha bandito otto entità tecnologiche affiliate alla Cina nel perseguimento di una strategia mirata ad impedire che le tecnologie emergenti statunitensi vengano utilizzate o, peggio, sfruttate per progressi nel calcolo quantistico della Cina funzionali ad applicazioni militari con conseguenziale sviluppo della capacità di violare la crittografia o sviluppare crittografia infrangibile. A questo riguardo, proprio in questi giorni, i capi dell'MI5 e dell'FBI ha diramato un avviso congiunto sulla crescente minaccia dalla Cina.

In particolare, il direttore dell'FBI Christopher Wray ha affermato che il governo cinese "rappresenta la più grande minaccia a lungo termine per la sicurezza economica e nazionale, per il Regno Unito, gli Stati Uniti e gli alleati in Europa e altrove”. Wray ha poi chiaramente avvertito che il governo cinese "rappresenta una minaccia ancora più seria per le imprese occidentali ed è pronto a rubare le loro tecnologie”. Ne consegue che l’annuncio del NIST va accolto con la consapevolezza che la corsa alla crittografia post-quantistica è allo stesso tempo una questione di sicurezza nazionale, sul piano geo-politico globale, e di privacy (confindentiality del dato) nell’ecosistema digitale dell’internet of everything. Ed infatti, va detto che, sebbene gli attuali algoritmi di crittografia siano abbastanza sicuri contro gli attacchi convenzionali, non sono tuttavia resistenti e non lo saranno certamente a tendere, agli attacchi quantistici, motivo per cui (in parte) i governi di tutto il mondo stanno allocando miliardi di investimenti per la nuova corsa all’oro. In tale scenario, mentre lo sviluppo della tecnologia quantistica prosegue alacremente, non si può trascurare uno scenario in cui attori ostili e criminal hackers esfiltrino set di dati crittografati, riservandosi di applicare, solo in un secondo momento lo sfruttamento quantistico. Per queste ragioni, il NIST e la Cybersecurity and Infrastructure Security Agency (CISA), al fine di meglio prepararsi al potenziale rilascio nel 2024 di nuovi standard crittografici, raccomandano di fare l'inventario dei sistemi organizzativi per le applicazioni che utilizzano la crittografia a chiave pubblica e di testare gli standard (quando ufficialmente rilasciati) in un ambiente di laboratorio. Sarà comunque fondamentale prepararsi al meglio per educare e preparare le infrastrutture pubbliche, private e critiche per questa nuova transizione. Mentre lo standard è in fase di sviluppo, il NIST incoraggia comunque gli esperti di sicurezza a esplorare i nuovi algoritmi e considerare come le loro applicazioni li utilizzeranno, ma non a inserirli ancora nei loro sistemi, poiché gli algoritmi potrebbero cambiare leggermente prima che lo standard sia finalizzato. Per noi di Vortici.it una cosa è sicura: l'informatica e la tecnologia, si stanno evolvendo in fretta, grazie a una spinta propulsiva non indifferente, dovuta a condizioni che ne hanno accelerato le applicazioni in diversi ambiti, geopolitica compresa(gli ultimi tre anni sono stati una palese dimostrazione di tutto questo). La digitalizzazione è diventata una condizione imprescindibile e con essa la protezione dei nostri dati!   Se hai letto questo articolo, forse potrebbe interessarti anche... La sottile linea della privacy   * Abbiate cura di voi, dei vostri cari e dei vostri amici.   Immagine di copertina e altre immagini : Pixabay Foto: AIDR Read the full article

[dinfunisa]

Uno stupendo articolo su come Hans Luhn inventò gli algoritmi di hash, ma anche brevettò una maniera per creare drinks sulla base degli ingredienti! http://bit.ly/dinfunisa-hash-drinks http://bit.ly/2ItlH91

[ryadel]

Come creare un certificato TLS SSL self-signed per Apache o NGINX con Linux CentOS

In questo articolo illustreremo come creare un certificato TLS / SSL auto-firmato e configurarlo all'interno di un web server Apache o Nginx per consentire connessioni sicure e crittografate. La prima parte del tutorial è dedicata a una breve introduzione del concetto di HTTPS, seguita da un approfondimento dei protocolli di sicurezza SSL e TLS; nella seconda parte parleremo di come utilizzare lo strumento openssl per procedere alla creazione del certificato TLS / SSL auto-firmato; ovviamente, qualora abbiate già acquistato (o intenzione di acquistare) un certificato TLS / SSL da una Certification Authority, potrete passare direttamente alla terza e ultima parte, dedicata alla Configurazione del certificato TLS / SSL su Apache e/o Nginx.

Introduzione

La sigla HTTPS è un acronimo/crasi di HyperText Transfer Protocol over Secure Socket Layer: si tratta di un protocollo di comunicazione sicura utilizzabile da due sistemi (peer-to-peer o client-server) che hanno l'obiettivo di scambiarsi informazioni tra loro. La porta utilizzata convenzionalmente è la TCP 443. La principale differenza tra HTTPS e il "cugino" HTTP (HyperText Transfer Protocol) sta nel fatto che il primo, a differenza del secondo, consente lo scambio di informazioni attraverso una connessione criptata tramite un protocollo crittografico asimmetrico come il Transport Layer Security (TLS) o il suo predecessore, Secure Sockets Layer (SSL). L'utilizzo di HTTPS in luogo del semplice HTTP garantisce alla connessione una serie di caratteristiche di sicurezza estremamente importanti, tra cui: Protezione delle informazioni e quindi anche della privacy delle parti comunicanti, nel rispetto dei criteri di riservatezza e confidenzialità. Garanzia dell'integrità dei dati scambiati tra le parti comunicanti. Verifica e autenticazione del trasmittente, ovvero del sito web visitato, o di entrambe le parti, nei casi di autenticazione duplex (vedi sotto). Fino ai primi anni 2000 l'utilizzo del protocollo HTTPS era limitato ai siti di e-commerce, alle connessioni inter-aziendali e a una serie di servizi corporate ed enterprise che trattavano dati particolarmente sensibili o riservati: la maggior parte dei siti web non ne faceva uso, anche e soprattutto per via delle risorse hardware necessarie per effettuare le attività di encrypt e decrypt richieste nel corso della connessione. A partire dalla metà dei 2000 e, soprattutto, dal 2010 in poi il protocollo HTTPS ha iniziato ad avere una larga diffusione, anche per merito dei browser e dei motori di ricerca, che ne hanno promosso e incoraggiato l'utilizzo in vari modi. I risultati di questa adozione ad ampio spettro sono estremamente positivi: l'utilizzo diffuso delle connessioni HTTPS garantisce l'autenticità delle pagine web visitate, aumenta la sicurezza degli account utente e protegge i dati che transitano sul web da accessi non autorizzati.

Transport Layer Security

Prima di affrontare l'utilizzo di openssl e dei relativi comandi terminal necessari per generare il certificato è opportuno spendere qualche parola sui protocolli di sicurezza TLS e SSL,così da comprendere al meglio perché è importante dotarsi di questo tipo di protezione. TLS, acronimo per Transport Layer Security e il suo predecessore SSL, o Secure Sockets Layer, sono protocolli crittografici che garantiscono un elevato livello di sicurezza delle comunicazioni attraverso una rete di computer: il loro utilizzo include tutte le principali connessioni TCP oggi utilizzate attraverso internet e non solo: web browsing, e-mail, invio di fax attraverso internet, messaggistica istantanea, protocolli VoIP, e molti altri. Una connessione TLS è contraddistinta dalle seguenti fasi principali: Negoziazione: in questa fase il server e il client stabiliscono quale protocollo di data-encryption utilizzare per la comunicazione sicura, il protocollo per lo scambio delle chiavi e l'algoritmo di autenticazione, nonché il Message Authentication Code (MAC). Scambio delle chiavi e autenticazione: in questa fase il server e il client si scambiano le informazioni relative alle chiavi crittografiche rispettivamente utilizzate, necessarie per decifrare correttamente i dati trasmessi e ricevuti. Sia l'algoritmo per lo scambio delle chiavi che quello per l'autenticazione sono normalmente algoritmi a chiave pubblica oppure (come nel caso del TLS-PSK) utilizzano una Pre-Shared Key, ovvero una chiave precondivisa. Cifratura simmetrica e autenticazione dei messaggi: in questa fase, l'integrità dei messaggi è garantita da un algoritmo di hash che usa un costrutto HMAC per il protocollo TLS o una funzione pseudorandom non standard per il protocollo SSL. Lo scopo principale di questi protocolli è duplice: Proteggere i dati in-transit e garantire la loro integrità attraverso algoritmi di data-encryption estremamente complessi e difficili da decifrare, anche a seguito di eventuali accessi non autorizzati (ottenuti mediante l'utilizzo di tecniche di attacco quali eavesdropping, tampering, man-in-the-middle, etc.). Garantire la reale identità della fonte di trasmissione - ad esempio un sito web - attraverso la certificazione di un ente formalmente autorizzato a fornire questo servizio, ovvero una Certification Authority: questa verifica viene effettuata mediante l'analisi del contenuto del certificato e il controllo dell'intera catena di certificazione. Come si può facilmente vedere, il primo aspetto riguarda la sicurezza e la protezione dei dati in senso stretto, mentre il secondo consente di verificare che il trasmittente sia chi dichiara di essere. Autenticazione unilaterale, duplex, PSK e SRP Nelle tipiche connessioni browser-server l'autenticazione TLS avviene in modo unilaterale, con il server web che si autentica presso il client ma non viceversa: questo significa che il client ha modo di conoscere e verificare l'identità del server a cui si connette pur restando anonimo. Il protocollo TLS supporta anche un'autenticazione bilaterale, tipicamente utilizzata in quegli scenari dove entrambi i peer oggetto della connessione (client e server, due webservice che comunicano tra loro, o altra situazione analoga) hanno necessità di autenticarsi in modo sicuro scambiandosi i relativi certificati. Questa tecnica di autenticazione, nota come autenticazione duplex (Duplex Authentication) e richiede ovviamente che anche il client possieda un proprio certificato digitale ed è normalmente utilizzata solo in scenari di connessioni aziendali o con enti pubblici. Un perfetto esempio di Duplex Authentication è quella prevista dalle specifiche tecniche del Sistema di Interscambio di Agenzia delle Entrate per il servizio SDICoop, basato per l'appunto sulla comunicazione tra due web service. In assenza di un'autenticazione bilaterale si possono utilizzare il protocollo TLS-PSK (Pre-Shared Key), di cui abbiamo già avuto modo di parlare, oppure il protocollo SRP (Secure Remote Password): entrambi consentono di effettuare un'autenticazione sicura in assenza di un certificato lato client. Green Bar Per riassumere quanto detto finora, possiamo dire che il certificato TLS consente di garantire sia la cifratura dei dati che la verifica del trasmittente. Nel momento in cui entrambe queste verifiche danno esito positivo il browser indica all'utente che la connessione è sicura mostrando l'icona di un lucchetto verde o un altro messaggio visivo analogo, a seconda del browser e delle caratteristiche del certificato stesso:

Questo tipo di evidenza visiva è detta green lock e garantisce l'utente che il proprio browser ha verificato con successo che la connessione è protetta da un certificato "genuino", ovvero rilasciato all'azienda proprietaria del sito. IMPORTANTE: E' opportuno precisare che tali verifiche non consentono di determinare che il sito a cui ci si sta connettendo sia intrinsecamente sicuro: è infatti del tutto possibile che un sito, benché protetto da un certificato genuino, possa contenere materiale potenzialmente pericoloso o veicolare contenuti fraudolenti. Per spiegare lo stesso concetto con una metafora, potremmo dire che le verifiche su cui si basa il green lock riguardano la sicurezza della serratura e la corrispondenza tra l'indirizzo della casa e il suo proprietario effettivo, ma non entrano nel merito di quello che possiamo trovare oltre la porta d'ingresso.

Certificati Auto-Firmati

Con il termine auto-firmato (o self-signed, in lingua inglese) ci si riferisce a un certificato generato dal proprietario del sito o servizio a cui ci si sta connettendo anziché da una autorità di certificazione attendibile: in altre parole, si tratta di un certificato che consente la piena crittografia dei dati trasmessi ma che non fornisce alcuna garanzia della reale identità della fonte di trasmissione, in quanto emesso dal diretto interessato e non da una "terza parte" autorizzata. Inutile dire che, vista l'impossibilità di garantirne l'attendibilità del certificato in modo oggettivo, qualsiasi certificato self-signed non sarà mai accompagnato da un green lock. Al contrario, la quasi totalità dei browser moderni reagisce a questo tipo di certificati visualizzando una serie di warning visuali all'utente, informandolo dei rischi che corre rispetto a un sito SSL realmente sicuro:

Si tratta di un warning che, a prima vista, può apparire esagerato: che un sito HTTPS protetto da un certificato self-signed è comunque notevolmente più sicuro di un sito HTTP, visto che i dati trasmessi e ricevuti vengono comunque criptati. Se però consideriamo che le connessioni HTTPS sono generalmente considerate sicure e affidabili dall'utente medio, è facile comprendere come la premura da parte del browser di avvisarci immediatamente che c'è qualcosa che non va sia pienamente giustificata. L'utente posto di fronte a questo avviso è costretto a prendere atto del fatto che l'identità del server a cui sta cercando di connettersi, a dispetto quanto la URL potrebbe far pensare, non è garantita da nessuno: può quindi scegliere di continuare consapevolmente la connessione oppure di rinunciare, a seconda della fiducia riposta nel server stesso. Quando ha senso utilizzare un Certificato Self-Signed? Veniamo dunque alla domanda più importante di questa lunga introduzione: quando ha senso utilizzare un certificato SSL auto-firmato? La risposta può essere dedotta facilmente da quanto chiarito nell'ultimo paragrafo: in tutti i casi in cui abbiamo necessità di garantire una connessione criptata a un server accessibile solo a un ristretto numero di utenti autorizzati, ovvero a noi stessi o colleghi-compagni-amici-chiunque altro che non abbia motivo di "dubitare" del suddetto server. Gli scenari tipici in cui questo tipo di certificato può essere utilizzato senza problemi includono tutti quei siti e servizi amministrativi con una GUI web-based chiusi al pubblico e aperti soltanto ad alcune specifiche utenze amministrative. Al contrario, installare un certificato auto-firmato su qualsivoglia sito o servizio aperto al pubblico avrebbe ben poco senso, visto che la mancanza di green lock e la presenza dei warning di cui sopra suonerebbero come un campanello d'allarme per tutti gli utenti.

Creare un certificato SSL Auto-Firmato

Ora che abbiamo messo a fuoco il perimetro d'uso ideale di un certificato SSL self-signed, vediamo come è possibile crearlo e configurarlo su un web server di tipo Apache e/o Nginx. Gli esempi riportati in questo paragrafo sono relativi a una macchina Linux CentOS ma possono essere utilizzati su tutte le principali distribuzioni Linux (e persino su sistemi Windows, utilizzando il porting di openssl per Windows). La prima cosa da fare è creare una cartella di tipo  /etc/ssl/private/ sul nostro server, che sarà utilizzata per memorizzare la chiave privata relativa al certificato SSL/TLS. La riservatezza di questo file sarà essenziale, quindi è opportuno proteggere la cartella appena creata da qualsivoglia accesso non autorizzato nel seguente modo: mkdir /etc/ssl/private/ sudo chmod 700 /etc/ssl/private/ Una volta fatto questo, possiamo utilizzare il tool openssl - incluso in tutte le principali distribuzioni Linux - per creare il certificato e la relativa chiave con un singolo comando terminal: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/httpd-selfsigned.key -out /etc/ssl/certs/httpd-selfsigned.crt Come si può vedere, mentre la chiave sarà creata nella cartella che abbiamo creato pochi istanti fa, il certificato vero e proprio verrà generato nella directory di sistema /etc/ssl/certs , che dovrebbe già esistere sul server (e contenere una serie di certificati ad uso interno) ed essere già dotata di tutti i permessi di accesso necessari. Ecco una breve spiegazione degli switch che abbiamo utilizzato: req - è il comando per la generazione della richiesta di emissione del certificato (CSR, ovvero Certificate Signing Request). x509 - identifica lo standard di formato del certificato (X.509). days - definisce il numero di giorni di validità del certificato. newkey - indica la volontà di creare una chiave privata. rsa:2048 - indica la volontà di creare una chiave privata utilizzando il RSA key processor a 2048 bit. keyout - il percorso completo dove sarà creata la chiave privata (solitamente un file con estensione .key). out - il percorso completo dove sarà creato il certificato (solitamente un file con estensione .crt). Il comando, una volta eseguito, chiederà all'utente di rispondere alle domande seguenti, necessarie per generare correttamente la CSR: Country Name (2 letter code) : il codice ISO 3166-1 (due lettere) della country, ovvero del paese di origine del certificato. Ad esempio: US State or Province Name (full name) : il nome dello stato o della provincia. Ad esempio: Massachusetts Locality Name (eg, city) : il nome della città. Ad esempio: Boston Organization Name (eg, company) : il nome dell'azienda (o della persona) che sta creando il certificato. Ad esempio: My Company, Inc. Organizational Unit Name (eg, section) : il settore, ramo, categoria merceologica o area di attività dell'azienda che crea il certificato. Ad esempio: Information Technology Common Name (eg, your name or your server's hostname) : il dominio o hostname su cui si desidera installare questo certificato. Ad esempio: example.com Email Address : l'indirizzo e-mail dell'amministratore di sistema. Ad esempio: ftp-admin@example.com I campi vanno compilati correttamente, prestando particolare attenzione al Common Name: è necessario che il valore impostato all'interno di quel campo corrisponda a un domain name associato al server (o che risolva su un indirizzo IP associato al server) su cui andremo ad installare il certificato. Creare un file dhparam.pem Per incrementare la sicurezza  dell'handshaking TLS effettuato tra il nostro server e i client ad ogni connessione è opportuno spendere qualche altro minuto del nostro tempo per creare un file dhparam.pem, ovvero un gruppo moltiplicativo Diffie-Hellman. Per farlo, digitare questo comando: sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 L'operazione durerà alcuni minuti, durante i quali il server provvederà a generare il gruppo: al termine dell'attività, il file dhparam.pem sarà generato nella cartella /etc/ssl/certs/ , pronto per essere utilizzato nella nostra configurazione.

Configurazione di Apache

Installare il nostro certificato self-signed su Apache è estremamente semplice: dobbiamo soltanto aggiungere i seguenti parametri di configurazione all'interno dell'elemento relativo al sito o servizio web all'interno del file  /etc/httpd/conf/httpd.conf  : DocumentRoot /var/www/example.com # ... # # ... HostNameLookups off ServerName www.example.com SSLEngine on SSLCertificateFile /etc/ssl/certs/httpd-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/httpd-selfsigned.key SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem" Volendo cogliere l'occasione per impostare un redirect di tutto il traffico non-HTTPS su HTTPS, è possibile aggiungere le linee seguenti: ServerName www.example.com Redirect 301 / https://www.example.com/ Per impostare redirect più complessi, ad esempio solo limitatamente ad alcune sotto-cartelle del sito, consigliamo di leggere questo articolo (paragrafo ISAPI REWRITE 3, che presenta una sintassi compatibile con Apache).

Configurazione di Nginx

Ecco come modificare il file di configurazione /etc/nginx/nginx.conf  per far sì che il nostro sito web example.com possa accettare connessioni HTTP con il certificato creato nei paragrafi precedenti: server { listen 443 http2 ssl; listen :443 http2 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/httpd-selfsigned.crt; ssl_certificate_key /etc/ssl/private/httpd-selfsigned.key; ssl_dhparam /etc/ssl/certs/dhparam.pem; ######################################################################## # from https://cipherli.st/ # # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html # ######################################################################## ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"; ssl_ecdh_curve secp384r1; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; ################################## # END https://cipherli.st/ BLOCK # ################################## } L'ultimo blocco di direttive contiene una serie di impostazioni che aumentano notevolmente la sicurezza delle connessioni HTTPS negoziate da Nginx: questi parametri sono consigliati da un articolo di Remy van Elst pubblicato su Cipherli.st, un sito di divulgazione specializzato sul tema della sicurezza informatica. Per approfondire le scelte che hanno portato alla loro definizione, consigliamo la lettura integrale dell'articolo: Strong SSL Security on Nginx. Anche nel caso di Nginx, qualora avessimo la necessità di impostare un redirect di tutto il traffico non-HTTPS su HTTPS, potremmo aggiungere le linee seguenti: server { listen 80; listen :80; server_name example.com; return 301 https://$host$request_uri/; }

Conclusioni

Per il momento è tutto: ci auguriamo che questo articolo possa aiutare utenti e amministratori di sistema a far luce sui certificati SSL e a configurare i propri server web in modo sicuro ed efficace. Alla prossima e... felice configurazione!   Read the full article

[pctfacile]

Da test effettuati a partire da un caso reale, siamo venuti a conoscenza di un problema che riguarda la verifica delle firme PAdES effettuata con le attuali versioni di Acrobat Reader DC, Acrobat Reader 11 ed Acrobat Pro 11.

Com’è  stato reso noto anche attraverso il sito dell’Agid, “Le attuali versioni di Acrobat XI e DC, consentono di verificare le firme digitali basate su certificati di firma rilasciati da tutti i certificatori accreditati stabiliti nell’Unione europea.  Adobe ha infatti reso disponibile il supporto alle Liste di fiducia (Trusted List) pubblicate dalle autorità di vigilanza degli Stati membri in conformità con la normativa comunitaria, dimostrando grande attenzione alle esigenze dell’Unione europea“: tale pur apprezzabile innovazione introdotta da Adobe, però, parrebbe perfettibile, se è vero – come abbiamo avuto modo di sperimentare – che la verifica  delle firme PAdES effettuata con le nuove versioni dei ricordati software restituisce all’apparenza un esito positivo pur essendo stata apposta al documento una firma invalida perché realizzata con un algoritmo (lo SHA1) non più utilizzabile da giugno 2011.

Per meglio comprendere tale questione, che non è meramente tecnica, va ricordato che il sistema delle firme digitali si basa sull’utilizzo su un certificato (chiave privata) di firma rilasciato da un “soggetto certificatore”[1]. L’apposizione di una firma si realizza mediante l’applicazione di un algoritmo (vale a dire un procedimento di calcolo) da cui si ottiene l’impronta del documento (message digest). Tale impronta viene codificata col predetto certificato e, all’esito di tale procedimento, il documento è reso immodificabile.

L’impronta codificata del documento è poi confrontabile con la chiave pubblica del certificato, esposta a cura dell’ente certificatore (inserito nelle c.d. trusted list), il che consente di stabilire, mediante l’utilizzo di appositi strumenti informatici, chi ha firmato quel dato documento e se questo sia stato modificato o meno dopo la firma.

Ovviamente, tutto ciò presuppone l’utilizzo di un certificato di firma valido nel momento in cui il soggetto appone la firma digitale e l’utilizzo di un algoritmo “sicuro”: è tale quell’algoritmo che garantisca l’univocità dell’impronta del documento cui il certificato viene associato.

Tali algoritmi adoperati per le firme digitali sono detti anche asimmetrici,  perché implementano due funzioni: una piuttosto semplice, per crittografare,  e l’altra più complessa per decrittografare: ciò serve perché è essenziale che dal codice generato dall’associazione della firma all’hash non si possa risalire alla chiave privata.

Orbene, l’algoritmo SHA-1 , inventato nel 1995, è ormai da tempo ritenuto dalla scienza informatica obsoleto e poco sicuro, tant’è che per effetto dell’art. 4 della delibera CNIPA 45/2009[2] così come modificato dalla Determinazione Commissariale 28 luglio 2010, per le firme apposte dopo il 30 Giugno 2011 deve essere, sia quanto al formato CAdES che a quello PAdES, adoperato  un algoritmo di hashing SHA256.

Vale la pena ribadire che l’utilizzo di tale più robusto algoritmo di cifratura è previsto a garanzia dell’integrità delle firme stesse e dei relativi certificati sicché l’apposizione di una firma con l’algoritmo deprecato SHA1 implica che la firma si debba ritenere per non apposta ai sensi dell’art. 24, comma 4-bis del CAD in riferimento ai commi 3 e 4 della stessa norma, per violazione delle regole tecniche ex art. 71 CAD.

Non a caso, le stesse regole tecniche per il processo civile telematico (DM 44/2011) prescrivono all’art. 11 il rispetto delle specifiche ex art. 34 dello stesso DM e, segnatamente, dell’art. 12, comma 2, che in materia di firme elettroniche prescrive che “La struttura del documento firmato è PAdES-BES (o PAdES Part 3) o CAdES-BES”.

Detto ciò, veniamo al caso pratico ed all’ “esperimento” eseguito.

Premettiamo anzitutto che l’errore nell’apposizione della firma si verifica allorché la firma stessa venga apposta dall’interno di Acrobat Reader  senza aver preventivamente impostato quest’ultimo per l’utilizzo dell’algoritmo corretto: su questo blog abbiamo più volte illustrato come si realizza tale impostazione, con un videotutorial realizzato dall’avv. Riccardo Berti (CSPT) ed altre analoghe istruzioni sono state pubblicate anche sul sito del Centro Studi Processo Telematico (cspt.pro).

Da questo link è possibile scaricare un documento volutamente firmato in PAdES senza le impostazioni corrette, affinché ciascuno possa provare direttamente: eppure, aprendo il file con Acrobat DC , questo evidenzierà (erroneamente) nella barra superiore che la firma è valida!

Così pure è anomalo il fatto che, procedendo con le ulteriori verifiche della firma con le funzionalità del software di Adobe, emerga (falsamente) che è stato utilizzato l’algoritmo SHA256:

In realtà, com’è possibile verificare dalle più approfondite “proprietà avanzate” del pannello di firma, l’algoritmo usato è lo SHA1, pur evidenziandosi incredibilmente una presunta conformità della firma stessa al Regolamento eIDAS (UE 910/2014):

Procedendo invece alla verifica con altro software (es. DIKE 6) verrà svelata l’invalidità della firma:

Consigliamo pertanto vivamente a tutti i colleghi:

a) di impostare preventivamente Acrobat Reader per l’apposizione delle firme con l’algoritmo corretto, come illustrato qui

b) di non limitarsi – fino a quando Adobe non avrà provveduto ad eliminare gli illustrati bug – alla verifica delle firme col predetto software ma di approfondire verificandone quantomeno le proprietà avanzate o di ricorrere congiuntamente ad altri verificatori.

[1] Cfr. art. 3, n. 20, Regolamento UE 910/2014: “«prestatore di servizi fiduciari qualificato», un prestatore di servizi fiduciari che presta uno o più servizi fiduciari qualificati e cui l’organismo di vigilanza assegna la qualifica di prestatore di servizi fiduciari qualificato” in riferimento all’art. 24 ed agli artt. 30 e ss dlt 82/2005.

[2] Art. 4 (Funzioni di hash) 1. I certificatori accreditati devono utilizzare per la sottoscrizione dei certificati elettronici di certificazione, di sottoscrizione e di marcatura temporale e per la sottoscrizione delle relative CRL, il seguente algoritmo, definito nella norma ISO/IEC 10118-3:2004: dedicated hash-function 4, corrispondente alla funzione SHA-256. 2. Le applicazioni di generazione della firma digitale per la sottoscrizione dei documenti informatici devono utilizzare la funzione di hash indicata al comma 1. (2) 2-bis. Salvo quanto disposto dall’articolo 27, comma 4, le applicazioni di verifica della firma digitale per la sottoscrizione dei documenti informatici devono utilizzare la funzione di hash indicata al comma 1. (3) 2 Comma sostituito dalla Determinazione Commissariale DIGITPA n.69 del 28 luglio 2010 (GURI n. 191 del 17 agosto 2010). 5 3. Le applicazioni di generazione e verifica della marca temporale devono utilizzare la funzione di hash indicata al comma 1. 4. Fino allo scadere dei termini previsti nell’articolo 29 della presente deliberazione, i certificatori accreditati devono utilizzare il seguente algoritmo, definito nella norma ISO/IEC 10118-3:2004: dedicated hash-function 3, corrispondente alla funzione SHA-1.

http://ift.tt/16xcFSA

[crypto28ro]

X16R – Algoritmul Dinamic de Proof-of-Work pentru Criptomonede

IntroducereÎn lumea criptomonedelor, algoritmii de proof-of-work (PoW) sunt esențiali pentru securizarea rețelelor și validarea tranzacțiilor. Unul dintre acești algoritmi inovatori este X16R, folosit inițial de criptomoneda Ravencoin și adoptat de și alte proiecte alternative. X16R se remarcă prin utilizarea unei lanțuri dinamice de 16 funcții de hashing, menită să descurajeze centralizarea…