Appunti Crittografia

Problema: Bob e Alice si devono scambiare messaggio in modo che anche se viene intercettato nessuno lo possa decriptare ma lo possono leggere solo
i destinatari.
Possibile soluzione: Entrambi avranno una chiave Pubblica,che conoscono tutti, e una chiave privata, personale e segreta.

– Un messaggio cifrato con la chiave PUBBLICA di bob puo essere aperto solo dalla chiave PRIVATA di Bob. Quindi lo puo leggere solo lui. Il problema è che chiunque puo usare la chiave pubblica di Bob per cifrare quindi non sono sicuro che l abbia spedito Alice (Autenticita non rispettata)

– Un messaggio cifrato con la chiave PRIVATA di bob puo essere  aperto solo dalla chiave PUBBLICA di Bob. Sono sicuro che il messaggio è stato mandato da Bob. Il problema è che chiunque abbia la chiave pubblica di Bob può leggere il messaggio(confidenzialità non rispettata)

– Un messaggio  cifrato con la chiave privata si dice “FIRMATO

Firma digitale di un documento
tramite  una funzione  hash (pubblica) si ricava l’impronta digitale del documento, detta anche message digest, ossia un file di dimensioni relativamente piccole (160 bit) che  contiene una sorta di codice di controllo relativo al documento stesso.
La funzione hash è fatta in modo da rendere minima la probabilità che  da testi diversi si possa ottenere il medesimo valore dell’impronta, inoltre, è one-way, a senso unico, questo significa che dall’impronta è  impossibile ottenere nuovamente il testo originario ovvero essa è non invertibile.
Dopodiché si utilizza la propria chiave privata per cifrare  l’impronta digitale: il risultato di questa codifica è la firma.  A questo punto la firma viene allegata al documento.Chiunque può verificare l’autenticità di un documento: per farlo, decifra la firma del documento con la chiave pubblica del mittente, ottenendo l’impronta digitale del documento, e quindi confronta quest’ultima con quella che si ottiene applicando la funzione hash al documento ricevuto;   se le due impronte sono uguali, l’autenticità e l’integrità del documento sono garantite. Quindi quando qualcuno firma un documento garantisce che tutto quello scritto la dentro è vero. Il ricevente a modo di verificare che il contenuto non sia stato modificato durante il tragitto.

Crittografia a chiave pubblica 
 Il mittente codifica due volte l’informazione:
 • con la propria chiave privata
 • con la chiave pubblica del destinatario
 Il destinatario deve effettuare una doppia decodifica per leggere l’informazione:
 • con la propria chiave privata
 • con la chiave pubblica del mittente
 In pratica, per motivi prestazionali, il client e il server usano questa tecnica per scambiarsi
 una chiave simmetrica in modo sicuro e poi passano a un algoritmo di crittografia tradizionale

– Per evitare la necessità di scambiare in anticipo in modo sicuro le chiavi pubbliche,  si usano certificati. Un certificato contiene una chiave pubblica autenticata mediante la firma digitale di una Certification Authority (CA).  Chi riceve il certificato può verificare direttamente l’autenticità della chiave pubblica usando la  chiave pubblica della CA (che deve essere nota).

-La maggior parte dei certificati comunemente utilizzati si basa sullo standard X.509 v3.

 – il certificato quindi è la chiave pubblica di tizio, garantisce per questo chi ha emesso il certificato ossia la CA, firmandolo con la sua chiave privata

– In genere i certificati contengono le informazioni seguenti:

  • il valore della chiave pubblica del soggetto
  • informazioni di identificazione del soggetto, quali il nome e l’indirizzo di posta elettronica
  • il periodo di validità (il periodo nel quale il certificato è considerato valido)
  • informazioni di identificazione dell’autorità di certificazione

-I certificati (quindi le chiavi pubbliche)ritenuti “fidati” sono memorizzati in un truststore.

– Nel keystore sono memorizzate la nostra chiave pubblica e private

-il truststore ha lo stesso identico formato del keystore ma ha una funzione diversa. Nel keystore ci sono la chiave privata e un certificato. Nel truststore c è il certificato.
Funziona il tutto cosi:
il server preleva il suo certificato dal suo keystore e lo spedisce al client. Il client
verifica che il certificato deve appartenere al server. Ossia lo deve avere nel suo truststore.
Quindi nel truststore vengono memorizzati i certificati ritenuti affidabili.
In generale tutti i client SSL devono avere un truststore. Se il server SSL richiede anche
l’autenticazione del client allora deve avere anche lui un trustore.
Riassumento allora abbiamo che il keystore serve per fornire le credenziali (chiave privata e chiave pubblica) mentre il truststore per verificare la chiave pubblica (o certificato). Spesso il keystore e il keytrust sono nello stesso file

– Il keystore puo contenere  coppie chiavi privata-certificato. Ogni coppia puo essere associata ad un alias.

– in java, in pratica, non si fa differenza tra trustore e keystore, si memorizza tutto nel keystore

-SSL supporta sia l’autenticazione lato server che quella lato client; nel primo caso, il più comune, il client controlla l’identità del server verificando che il certificato personale inviato dal server sia firmato da una CA che riconosce; per fare ciò deve disporre di un certificato  emesso dalla CA che ha firmato la chiave pubblica del server.Nel caso di autenticazione lato client invece, è il server che controlla l’identità del client verificando che il certificato inviato da quest’ultimo sia firmato da una CA riconosciuta. Pertanto nell’autenticazione lato server, il client deve possedere solo il certificato della CA del server, mentre nell’autenticazione lato client deve possedere, oltre al certificato  della CA del server, anche il suo certificato personale da inviare al server.

– Keystore e truststore sono gestiti tramite l’utility keytool del JDK.

Comandi importare e visualizzare certificati
importa i certificati
keytool -import -alias <NOME ALIAS> -file <NOME FILE CERTIFICATO.CER> -keystore <NOME KEYSTORE> -storepass <PASSWORD KEYSTORE>
la password dei keystore in genere è changeit. Si puo anche creare un keystore personale e usare quello.
visualizza i certificati
keytool –list -v -keystore <NOME KEYSTORE>

– keystore di sistema:
              $JAVA_HOME/lib/security/cacerts
 Contiene i certificati delle CA riconosciute

-Keystore utente:
               $HOME/.keystore
 Contiene le chiavi dell’utente e quelle che l’utente riconosce

-mostra il contenuto di un certificato
openssl x509 -inform pem -in wild.ordenacionjuego.gob.es.cer  -text

– file cer e file pem sono la stessa cosa

-Struttura di un certificato X.509 :

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         — If present, version MUST be v2 or v3
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         — If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         — If present, version MUST be v3
    }


-Un certificato PEM può essere letto con un semplice editor di testo e a al suo interno ha seguenti stringhe:
—–BEGIN CERTIFICATE—–
MIIB2zCCAUSgAwIBAwIBADANBgkqhkiG9w0BAQQFADAYMRYwFAYDVQQDEw1OZXRn

—–END CERTIFICATE—–

– si puo avere anche una  private key in PEM format, in questo caso ci potrebbe essere la stringa:
-BEGIN RSA PRIVATE KEY—–

Chiamare un servizio protetto Https con SOAPUI

Importare il certificato pubblico del server, ossia posizionarsi nella cartella:

…….SoapUI-4.6.4jrelibsecurity

eseguire questo comando:

keytool -import -alias NOMEHOST -trustcacerts -keystore cacerts -file NOME_E_PATH_CERTIFICATO.cer

importante lanciare l’istruzione da amministratore!!!!!

per vedere quali certificati ci sono nel cacerts:

keytool -list -v -keystore cacerts




andare nel tab   WS-Security Configurations tab

selezionare il keystore con la  TUA chiave privata  e creare una nuova regola per i messaggi outgoing, ossia le request in uscita:

selezionare la firma delle request con gli appositi valori:

a questo punto posizionarsi sulla request soap, in basso a destra c è un tab AUTH   in cui si seleziona, tramite authentication, quale regola si deve applicare alla request. Selezionare la regola appena creata.

NB in molte versioni di SOAPUI c è un bug e a volte non funziona questo procedimento, ma con il software READAPI, della stessa casa di soapui, invece funziona sempre, almeno in quelle che ho provato io.