Il talk si propone di fornire strumenti utili ai developer che vogliono offrire ai propri utenti autenticazione ed autorizzazione da differenti canali quali mobile e browser su differenti tipi di risorse come web-application e REST services. Saranno mostrati gli algoritmi di crittografia ed i protocolli più noti di autenticazione/autorizzazione, evitando noie matematiche e considerando solo le applicazioni pratiche. Gli argomenti trattati saranno Crittografia (25 minuti) symmetric key, asymmetric key, key exchange, key derivation function, key management, hash function, MAC function Autenticazione e Autorizzazione (50 minuti) HTTPS, Password, autenticazione a 2 fattori, Cookie (stateful), Access Token (stateless), JWT,OAuth2 e OpenID Connect

1. OAuthorize yourself 2.0
Dalla crittografia ai protocolli web
Ciro Bologna
Security Architect presso QUI! Group S.p.A.
1

2. Agenda parte 1
• Crittografia
– Introduzione
– Symmetric Key
– Asymmetric Key
– Key Exchange
– Key Derivation Function
– Key Management
– Hash Function
– MAC Function
2

3. • Alice vuole inviare un messaggio a Bob
• Alice vorrebbe che Eve non capisca il messaggio
Secure
Channel
msg msg
$
#
/
3
Introduzione 1/3

4. Confidenzialità
• Il messaggio è leggibile solo dai destinatari
Integrità
• Il messaggio originale è inalterato durante la trasmissione da mittente a
destinatario
Disponibilità
• Il messaggio è fruibile per gli scopi cui è stato creato
Identità
• Attraverso un processo (autenticazione) si è garantiti che mittente e
destinatario siano chi dicono di essere
Non ripudiabilità
• Il mittente non può negare di aver trasmesso il messaggio
4
Introduzione 2/3

5. Introduzione 3/3
5
Ciphers
Classical
Substitution
Monoalphabetic Polyalphabetic
Transpositional
Modern
Symmetric
Block Cipher Stream Cipher
Aymmetric

6. Symmetric Key 1/3
• Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave
• Stessa chiave condivisa tra Alice e Bob (Ka=Kb=K)
6
Insecure
Channel
Encipher Decipher
plaintext plaintext
ciphertext ciphertext

7. Symmetric Key 2/3
• Considerazioni
– Scambio e memorizzazione della chiave?
– Bruteforce sulla chiave
– Analisi statistica
– Efficienza
– Confidenzialità ed Integrità
– Quale algoritmo?
7

8. Symmetric Key 3/3
• Modes of Operation, consigli del NIST
(National Institute of Standards Technology)
– ElectronicCodeBook
– CipherBlockChaining
– CipherFeedbackMode
– OutputFeedbackMode
– CounterMode
• Prestare attenzione ai parametri di
inizializzazione dell’algoritmo (es. random IV)
8

9. Asymmetric Key 1/3
• Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave
• Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv)
• Kpriv è disponibile solo a Bob, mentre Kpub è disponibile a tutti, tra cui Alice
9
Insecure
Channel
Encipher Decipher
plaintext plaintext
ciphertext ciphertext

10. Asymmetric Key 2/3
• Algoritmo noto pubblicamente, la sicurezza dipende dalla chiave
• Coppia di chiavi pubblica, privata appartenenti a Bob K=(Kpub,Kpriv)
• Kpriv è disponibile solo a Bob, mentre Kpub è disponibile ad Alice ed anche a Eve!
10
Insecure
Channel
Sign
Message
Verify
Digest
Message Trusted
Message
Message+Digest Message+Digest
Diges
t
Diges
t
Diges
t

11. Asymmetric Key 3/3
• Considerazioni
– Memorizzazione chiave privata?
– Problemi di Scambio Chiave risolti, la chiave per
cifrare è pubblica
– Bruteforce sulla chiave troppo costoso
– Scarsa efficienza
– Confidenzialità, Integrità, e Non ripudio
– Quale algoritmo?
11

12. Symmetric vs Asymmetric Key
• Raccomandazioni NIST su lughezza delle chiavi e
crittoperiodo https://www.keylength.com/en/4/
• In generale la crittografia a chiave asimmetrica è
utilizzata per scambiare e/o stabilire in maniera sicura
una chiave simmetrica valida per un periodo di tempo
limitato
• In base ad un’analisi dei rischi, la memorizzazione
potrebbe avvenire in locazioni/dispositivi dedicati con
adeguate proprietà di
– Tamper Resistance
– Tamper Evidence
– Tamper Responsivess
12

13. Key Exchange 1/2
• Es. Algoritmo Diffie Hellman tra Alice e Bob
13
Insecure
Channel
Compute Compute
Segreto
random a
Segreto
Random b
Valore A
pubblico
Valore B
pubblico
p, g Valori
Noti a Tutti
p, g, A, B ???
Compute Compute
a
B
p
b
A
p

14. Key Exchange 2/2
• Algoritmo Diffie Hellman
– Consente di calcolare lo stesso segreto condiviso
tra Alice e Bob senza che Eve possa ascoltarlo
– I valori segreti a e b non vengono mai trasmessi!
– L’idea di fondo è che Eve non abbia la capacità
computazionale necessaria a calcolarli
– Manca l’autenticazione! E’ possibile un attacco
man in the middle
14

15. Key Derivation Function 1/2
• Derivazione di una o più chiavi segrete a
partire da un segreto dell’utente come ad
esempio una password (es. Apple passcode)
• Sono computazionalmente costose per
rendere il cracking della chiave più difficile
15
KDF
SEGRETO
N iterazioni
SALT

16. • Es. supponiamo che Alice e Bob abbiano pre-condiviso un
segreto su un altro canale (es. posta, mail, SMS)
• Possono derivare ogni volta (es. ogni transazione) la stessa
chiave senza mai più trasmettere il segreto!
Key Derivation Function 2/2
16
KDF
ID_TRANSAZIONE
N iterazioni
SALT
KDF
SEGRETO
N iterazioni
SALT

17. Key Management
• NIST 800-130: A Framework for Designing Cryptographic
Key Management System
– Security Policies
– Roles and Responsibilities
– Cryptographic Keys and Metadata
– Security Controls
– Testing and System Assurances
– Disaster Recovery
– Security Assessment
– Technology Challenges
• La gestione delle chiavi crittografiche è il punto più
delicato, non solo dal punto di vista tecnologico, ma anche
negli aspetti gestionali nonché organizzativi
17

18. Hash Function
• Funzioni che hanno le seguenti proprietà
– Deterministiche
– Non invertibili
– Output a lunghezza fissa indipendentemente
dall’input
– Un piccolo cambio nell’input produce un output
totalmente diverso
– Resistenza alle collisioni
• Garantiscono Integrità se applicate ad un
messaggio? No!
18

19. MAC Function
• Combinazione di crittografia simmetrica e
funzioni di Hash
• E’ possibile ora garantire l’Integrità
• Porre sempre attenzione allo scambio della
chiave!
19
MAC
MAC

20. Agenda parte 2
• Autenticazione ed Autorizzazione
– Certificate
– HTTPS
– Password
– 2FactorsAuthentication
– Cookie
– Access Token JWT
– OAuth2
– OpenID Connect
20

21. Certificates 1/3
• Public Key Infrastructure
– Sistema gerarchico per l’emissione dei certificati
– Le Certification Authority (CA) nascono con l’obiettivo di garantire l’Identità
degli attori dello scambio di messaggi, che seguono delle procedure per
registrarsi alla CA
• Domain Validation
• Organization Validation
• Extended Validation
• X.509 v.3 definisce la struttura ed i campi presenti in un certificato
rilasciato da una CA
– Version, Serial Number, Signature Algorithm identifier, Issuer Name, Period of
Validity (Not Before, Not After)
– Subject Name, Subject’s public key info
– Issuer Unique Identifier, Subject Unique Identifier
– Extension (Key Usage)
– Signature (algorithm, parameters, encrypted hash)
21

22. Certificates 2/3
• Es. Catena dei certificati
22
La root CA firma con la sua chiave privata
il certificato della intermediate CA
L’intermediate CA firma con la sua chiave
privata il certificato associato allo
specifico dominio
Il certificato del dominio può essere
verificato con la chiave pubblica della
intermediate CA
Il certificato della intermediate CA può
essere verificato con la chiave pubblica
della root CA

23. Certificates 3/3
• Revoca anzitempo dei certificati
– compromissione della chiave
– utente non più certificato dalla CA
– il certificato della CA è compromesso
• Certificate Revocation List
– la CA mantiene aggiornata la lista dei certificati revocati
– il client dovrebbe verificare la CRL, non necessariamente aggiornata
• OCSP Online Certificate Status Protocol
– Più recente, consente la verifica del singolo certificato interrogando un
servizio real time
• https://letsencrypt.org/getting-started/
• https://ietf-wg-acme.github.io/acme/
23

24. HTTPS 1/3
• https://tools.ietf.org/html/rfc2818
– Conceptually, HTTP/TLS is very simple. Simply use HTTP
over TLS precisely as you would use HTTP over TCP
• Obiettivi TLS – Confidenzialità ed Integrità
– TLS Record Protocol
• Crittografia simmetrica
• MAC con chiave simmetrica
– TLS Handshake Protocol
• Crittografia asimmetrica
• Negoziazione sicura di un segreto condiviso
• Negoziazione affidabile
• Per ogni sessione c’è una nuova chiave simmetrica
scambiata grazie alla crittografica asimmetrica
24

25. HTTPS 2/3
• PKI e CA rendono possibile l’applicazione di
HTTPS
• I browser hanno una lista di CA note
• E’ possibile fidarsi di CA private inserendo in un
trust-store le chiavi pubbliche, generalmente
evitare certificati Self-Signed
• Mutua autenticazione
– Entrambe le parti sono verificate
– Costi di gestione
– Dove memorizzo la chiave privata del client?
25

26. HTTPS 3/3
• L’implementazione del protocollo non è immune
da falle di sicurezza
– Utilizzare ultima versione del protocollo TLS v1.2
– Forzare l’utilizzo di cifrari aggiornati
– Non consentire downgrade dei cifrari in fase di
handshake
• Valutazione Certificate Pinning
– https://www.owasp.org/index.php/Certificate_and_P
ublic_Key_Pinning
– Prestare attenzione alla certificate rotation
– Utile per mobile app
26

27. Password 1/2
• Strong Password a seconda di una opportuna analisi di rischio
– Utilizzo di regex sia front-end che back-end
– Es. PCI-DSS 7 caratteri, 1 minuscola, 1 maiuscola, 1 numero, 1
carattere speciale, diversa dalla username, e diversa dalla password
precedente
• Memorizzazione sul database utilizzando funzioni di hash
– Utilizzare salt random
– Utilizzare primitive crittografiche aggiornate
– Protezione del backup
• Trasmissione esclusivamente su HTTPS
– H “Authorization : Basic Base64(username:password)”
– H “Content-Type : application/x-www-form-urlencoded”-d
“username=user&password=AxcC91$”
27

28. Password 2/2
• Punti di Attenzione
– Infrastruttura
• SSL Offloading
• Web Server/Reverse Proxy
• Application Server
– File di Log
– Procedure di recovery password
• Mail dell’utente
• Backoffice di assistenza
– Aggiornamento periodico forzato es. 90 giorni
– Centralizzazione della gestione password in un
componente dedicato, evitando la trasmissione della
password tra le applicazioni
28

29. 2FactorsAuthentication 1/2
• Per Strong Authentication, si intende
l’applicazione di almeno 2 delle seguenti
– Something you know es. password, pin
– Something you have es. device, certificato
– Something you are es. biometria
• Attenzione alla fase di enrolment dei device
• Attenzione alla fase di acquisizione di dati
biometrici
– https://cubs.buffalo.edu/images/pdf/pub/symmetric-
hash-functions-for-secure-fingerprint-biometric-
systems.pdf
29

30. 2FactorsAuthentication 2/2
• Es. Password + OTP
– Utilizzare protocolli standard come ad esempio
HOTP, basato su HMAC
– In molti scenari utilizzare una soluzione software
di OTP garantisce una sicurezza sufficiente
– Utile in uno scenario mobile, dove è possibile
usare SMS o Notifiche sul device
• Es. Password + Certificato Client
– La mutua autenticazione con il certificato è una
strategia efficace in scenari enterprise
30

31. Cookie 1/2
• https://tools.ietf.org/html/rfc6265
– HTTP State Management Mechanism defines the HTTP Cookie and
Set-Cookie header fields
• Es. Browser utilizza webapp servita da Application Server
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
• Il server può anche modificare lo scope del cookie
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
• Il cookie sarà valido in ogni sottodominio di example.com
31

32. • == Server -> User Agent==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly;
Expires=Wed, 09 Jun 2021 10:18:14 GMT
• I cookie dovrebbero avere una scadenza piuttosto breve
• Il flag HttpOnly impedirà che i cookie siano accessibili via
Javascript
• Il Secure flag impedierà di inviare il cookie in assenza di
HTTPS
• Mitigazioni al CSRF – Cross Site Request Forgery
– Synchronizer Token Pattern
– Verificare header Referer e Origin
• Al solito, non affidarsi ad implementazioni custom
32
Cookie 2/2

33. Access Token 1/2
• I Cookie sono utili in un contesto di applicazioni
stateful, dove il server mantiene una sessione
• In un contesto di API RESTful è preferibile
un’autenticazione stateless
• Il server può generare un access_token come una
semplice stringa alfanumerica random
memorizzata nel WebStorage
(localStorage/sessionStorage HTML5) del client
– curl –H “Authorization : Bearer df15e2ff-95ea-3515-
a7b1-1ca8e1591547” –X GET
‘https://service/resource/1’
33

34. Access Token 2/2
• Un access_token ha una durata limitata ed a
seconda del contesto è possibile prevedere
meccanismi di refresh
• XSS – Cross Site Scripting
– Javascript può accedere al Web Storage, di
conseguenza è possibile effettuare code injection
nelle form
• <script>alert('You are Hacked');</script>
– Escape ed Encoding di tutti i dati untrusted
– OWASP Cheat Sheet
34

35. JWT 1/3
• JWT – JSON Web Token
– Un particolare tipo di access_token utilizzato per
scambiare informazioni (claims) tra le parti
– Tale informazioni sono firmate e pertanto possono essere
verificate
35
Header Body JWS - con chiave simmetrica

36. JWT 2/3
36
Header Body JWS - con chiave asimmetrica
• Numerose librerie a supporto su https://jwt.io/

37. JWT 3/3
• Nel caso JWS simmetrica prestare attenzione allo
scambio ed alla memorizzazione della chiave!
• Il JWT non dovrebbe avere informazioni sensibili, nel
caso sia necessario valutare il JWE che tra le sue
informazioni ha una Content Encrypted Key con cui
cifra i claims
• Replay Attack possono essere mitigati utilizzando un
nonce (jti claim), data di scadenza (exp claim), ed il
data di creazione (iat claim) tra i claims
• E’ possibile memorizzare i JWT nei Cookie!
37

38. • The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing
the third-party application to obtain access on its own behalf
• Ruoli coinvolti
– Resource Owner: un entità in grado di garantire l’accesso ad una
risorsa protetta. Quando tale entità è una persona, viene detta end-
user
– Resource Server: il server che espone le risorse protette e che ne
garantisce l’accesso in caso di access token valido
– Client: un applicazione che vuole accedere alle risorse protette con
l’autorizzazione del Resource Owner
– Authorization Server: il server che rilascia gli access token ai client
dopo una corretta autenticazione ed autorizzazione del Resource
Owner
38
OAuth2.0 1/6

39. • Registrazione
– Client si registra presso Authorization Server
specificando un redirect_uri (in HTTPS!)
– Riceve client_id (info pubblica) e secret (info privata)
• Grant Type
– implicit: mobile app, webapp frontend only
– authorization_code: webapp frontend + backend
– password: webapp frontend + backend nel caso in cui
Authorization Server e Resource Server coincidano
– client_credentials: server to server
39
OAuth2.0 2/6

40. • Grant Type implicit
– Endpoint /authorize indicando all’Authorization Server client_id e redirect_uri
– Redirect alla pagina di login dell’Authorization Server dove il Resource Owner si
autentica prima e poi autorizza il Client ad accedere ad i suoi dati
– Redirect al redirect_uri mostrando l’access_token
• https://localhost/index#access_token=7fbd257e-6184-3a33-873a-
1b690058292c&token_type=Bearer&expires_in=2807
– Accesso al Resource Server garantito grazie all’access_token
• curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359-acdbac9719b5'
'https://localhost:8243/test/1.0/resource'
• { "data" : "sample JSON"}
40
OAuth2.0 3/6

41. • Grant Type authorization_code
– Endpoint /authorize indicando all’Authorization Server client_id e redirect_uri
– Redirect alla pagina di login dell’Authorization Server dove il Resource Owner si
autentica prima e poi autorizza il Client ad accedere ad i suoi dati
– Redirect al redirect_uri mostrando l’authorization_code
• https://localhost/index?code=44d5aaf4-2012-326c-86fb-2c29f2f8c23e
– Endpoint /token indicando all’Authorization Server Base64(client_id, secret),
redirect_uri, authorization_code
• curl -k -d "grant_type=authorization_code&code=44d5aaf4-2012-326c-86fb-
2c29f2f8c23e&redirect_uri=https%3A%2F%2Flocalhost%2Findex" -H "Authorization: Basic
bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9NSFFh"
https://localhost:8243/token
• {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5”,
"expires_in": 1212,
"refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36”,
"scope": "default”,
"token_type": "Bearer”}
– Accesso al Resource Server garantito grazie all’access_token
• curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-3947-a359-
acdbac9719b5' 'https://localhost:8243/test/1.0/resource'
• { "data" : "sample JSON"}
41
OAuth2.0 4/6

42. • Grant Type password
– Endpoint /token indicando all’Authorization Server Base64(client_id, secret),
username, password
• curl -k -d "grant_type=password&username=end-user&password=Password1$" -H
"Authorization: Basic
bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9
NSFFh" https://localhost:8243/token
• {"access_token": "be987a62-f3f4-3947-a359-acdbac9719b5”,
"expires_in": 567,
"refresh_token": "23939ba5-5b17-3f71-916c-8042da3f2c36”,
"scope": "default”,
"token_type": "Bearer”}
– Accesso al Resource Server garantito grazie all’access_token
• curl -k -X GET -H 'Accept: application/json' -H 'Authorization : Bearer be987a62-f3f4-
3947-a359-acdbac9719b5' 'https://localhost:8243/test/1.0/resource'
• { "data" : "sample JSON"}
• Stiamo autenticando contemporaneamente sia Client che Resource
Owner in una sola chiamata
42
OAuth2.0 5/6

43. • Grant Type client_credentials
– Endpoint /token indicando all’Authorization Server Base64(client_id, secret)
• curl -k -d "grant_type=client_credentials" -H "Authorization: Basic
bFY4SDlxM0dPaWl4RnFlZjZZZTdvZV9USEFNYTp2V3ZfS21jbDlRQzU1ZDh1NDV0bENtVm9
NSFFh" https://localhost:8243/token
• {"access_token": "f93a66a2-d51a-341e-830a-a190dd4b2258”,
"expires_in": 278,
"scope": "am_application_scope default”,
"token_type": "Bearer”}
• Stiamo autenticando solo il Client e NON il Resource Owner!
• Lo scope di questo access_token è in genere differente dagli altri
grant_type e non è detto che garantisca l’accesso a tutte le risorse
presenti sul Resource Server
• Per ogni richiesta di token è possibile specificare un particolare scope, che
viene assegnato se e solo se chi richiede il token ne ha gli opportuni diritti
• Gli scope possono essere utili nel caso di fine grained authorization
43
OAuth2.0 6/6

44. • OpenID Connect è un identity layer sviluppato sulle basi di OAuth2.0, di
cui condivide gli endpoint /token, /authorize
• I Client non ricevono più semplici access_token bensì degli id_token,
ovvero dei JWT con i claim relativi ad un Resource Owner
• id_token standard claims
"at_hash": "nRQa2D-pBK3dbqrH0KaICw",
"sub": "end-user@carbon.super",
"aud": [
"lV8H9q3GOiixFqef6Ye7oe_THAMa"
],
"azp": "lV8H9q3GOiixFqef6Ye7oe_THAMa",
"auth_time": 1480476397,
"iss": "https://localhost:9443/oauth2/token",
"exp": 1480479997,
"iat": 1480476397
44
OpenID Connect 1/3

45. • L’endpoint /token risponderà quindi fornendo sia access_token che id_token
{
"access_token": "bd2fde09-1afd-3f35-a2f7-a1766312dedd",
"expires_in": 3052,
"id_token":
"eyJ4NXQiOiJObUptT0dVeE16WmxZak0yWkRSaE5UWmxZVEExWXpkaFpUUmlPV0UwTldJMk0ySm1PVG
MxWkEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiblJRYTJELXBCSzNkYnFySDBLYUlDdyIsInN1YiI6ImVuZC11
c2VyQGNhcmJvbi5zdXBlciIsImF1ZCI6WyJsVjhIOXEzR09paXhGcWVmNlllN29lX1RIQU1hIl0sImF6cCI6Imx
WOEg5cTNHT2lpeEZxZWY2WWU3b2VfVEhBTWEiLCJhdXRoX3RpbWUiOjE0ODA0NzYzOTcsImlzcyI6Imh0
dHBzOlwvXC8xOTIuMTY4LjEuNjo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNDgwNDgwMjQ0LCJpYXQi
OjE0ODA0NzY2NDR9.e5573sl-
szD4M3jX5SorGIYKNKNlEsmOpfM2qpVKGnzaRJyBOGEJt0gXbvAqWKlyOLrYP8rvDImQ9HlqbL60IbF0OwI0
z7LfJqWA2YcaQ5M3JWHQ3naM1uZi3mjWywnEcGzGUcftmCoJmgh4J48eZlDJpTQj2gW89nR_x1t-Xj4",
"refresh_token": "2892d0b3-12ec-399c-b575-e7accc128486",
"scope": "openid",
"token_type": "Bearer”
}
• Valgono le considerazioni sul JWT fatte in precedenza, bisogna verificarne la signature
45
OpenID Connect 2/3

46. • Inoltre è presente un endpoint /userinfo specifico per
recuperare standard claims relativi ad un utente
– è necessario invocare l’endpoint con gli opportuni scope
per ottenere i claim associati
• email - email, email_verified
• phone - phone_number, phone_number_verified
• profile - name, family_name, given_name, middle_name,
nickname, preferred_username, profile, picture, website, gender,
birthdate, zoneinfo, locale, updated_at
• address – address
– per non incorrere in problematiche di privacy è opportuno
utilizzare solo gli scope effettivamente necessari
46
OpenID Connect 3/3

47. • OpenID Connect è retrocompatibile
• OpenID Connect realizza una
standardizzazione per l’accesso alle
informazioni sull’identità dell’utente
• OAuth2 nasce come framework di
autorizzazione, mentre OpenID Connect come
framework di autenticazione
• OAuth2 lascia maggiore libertà
nell’implementazione della specifica
47
OAuth2.0 vs OpenID Connect 3/3

48. • In definitiva
– Utilizzare protocolli ed implementazioni standard
– Scegliere una determinata soluzione in base ai requisiti ed
i rischi associati
– Valutare sempre i costi di gestione delle chiavi
crittografiche
– Tenersi aggiornati costantemente, parte della crittografia
dipende dalle capacità computazionali
– Guardare alla sicurezza a 360 gradi, in generale si riesce a
definire sicuro un sistema, con un certo grado di rischio,
non solo grazie alla tecnologia, ma anche grazie ai processi
ed alle strutture organizzative a supporto
– Domande?
48
Conclusioni