Please enable JavaScript.

Coggle requires JavaScript to display documents.

Kerberos (Crittografia (Funzioni di Hash Crittografiche (Non è reversibile…

- - - - Segretezza
      - Autenticazione
      - Integrità
      - Non garantisce la "Non repudiabilità"
        
        Non è detto che il dato non possa essere stato modificato da qualcuno e quindi l'autore del dato ricevuto sia effettivamente chi pensiamo
    - - un sistema che ha n utenti avrà n^2 chiavi
        
        insomma tante chiavi da mantenere
      - Più è grande la dimensione della chiave più è sicura
        
        non bisogna però eccedere
        
        max 256-512 bit
      - Le chiavi vanno distribuite tra i vari utenti in qualche modo
        
        operazione delicata non banale
        
        bisogna trovare un modo sicuro per farlo
  - - - pubblica
        
        cifra i messaggi
        
        Non è in grado di decodificarli
        
        é data a tutti
      - Privata
        
        cifra e decifra i messaggi
        
        mantenuta segreta
    - - più lente da codificare e decodificare
      - Algoritmi RSA solitamente
    - - Segretezza
        
        Chi mi invia un mesaggio lo cifra con una chiave che solo io posso decriptare
        
        Se non hai la mia chiave privata non puoi conoscere il contenuto del messaggio
      - Non repudiabilità
        
        Se il mittente mi manda un messaggio cifrato con la sua chiave privata, io potrò decifrarlo con la sua chiave pubblica
        
        ciò mi garantisce che il mittente è colui che ha la chiave privata ( può anche essere ciuffata, però devi riuscirci, non vi è scambio della chiave privata, quindi è più difficile impossessarsene
      - Autenticazione
        
        Mittente cifra il messaggio prima con la sua chiave privata e poi con la mia chiave pubblica avrò due certezze
        
        Se posso decifrarlo con la sua chiave pubblica allora il messaggio sarà inviato certamente da lui
        
        La garanzia di segretezza dato che poi solo io potrò decifrare il contenuto attraverso la mia chiave privata
      - Integrità
        
        Il meccanismo descritto prededentemente per l'autenticazione garantisce anche che i dati non possano essere modificati altrimenti il processo di decriptazione non andrebe a buon fine
        
        Quindi garantisce anche l'integrità dei dati
  - - - cifrare un informazione attraverso un'apposita chiave in modo che questa non sia intellegibile a meno di non possedere la chiave di decodifica
    - - decifrare un informazione che è stata precedentemente codificata in una certa maniera
  - - - é una sorta di riassunto digitale del messaggio
    - - Non possono esistere due messaggi che abbiano il digest uguale
      - Se due messaggi sono simili i digest devono essere molto diversi
    - - non prevedono l'uso di una chiave
    - - MD5
        
        Superdeprecato
        
        Totalmente Insicuro
        
        1991
        
        Message Digest 5
      - SHA
        
        Secure Hash Algoritm
        
        SHA-1
        
        160 bit
        
        Oggi non sicuro
        
        SHA-2
        
        SHA-X
        
        SHA-128...512
        
        generano digest di grandezza fissa specificata dalla X
        
        ad esempio 256 bit, 512bit etc
        
        Lunghezza e tempo di calcolo aumentano all'aumentare della dimensione del digest
  - - - Autenticare l'origine del messaggio
      - Garantire l'integrità
    - - Crittografia simmetrica
        
        Mac vero e proprio
      - Crittografia asimmetrica
        
        Firma digitale
    - - Ricezione
        
        ricevo un messaggio m
        
        scorporo il messaggio dal digest crittografato
        
        decripto il digest e lo confronto con il digest di m
        
        Se il due digest coincidono allora il messaggio è esattamente quello che è stato mandato in origine
        
        Se i digest non coincidono il messaggio è stato modificato e non è mantenuta quindi l'integrità
      - Spedizione
        
        voglio mandare un messaggio m
        
        mi calcolo il suo digest
        
        Invio il messaggio in chiaro concatenato dal digest crittografato ( simmetrica o asimmetrica a seconda del caso)
    - - Variante Simmetrica
        
        Integrità
        
        Posso sapere se il messaggio che mi arriva è stato modificato in qualche modo
        
        Autenticazione
        
        Chi mi manda il messaggio è a conoscenza della chiave
        
        posso (forse) fidarmi che sia lui
        
        non garantisce la non repudiabilità
        
        posso certamente mandarmi da solo un messaggio da solo in qualsiasi caso, ciò non garantisce la non repudiabilità
      - Variante asimmetrica
        
        Integrità
        
        Autenticazione
        
        il digest che mi arriva è stato crittografato con la chiave privata del destinatario, posso certamente sapere che chi me la manda la conosce e (forse) mi posso fidare
        
        Non repudiabilità
        
        Non sono a conoscenza della chiave privata del mittente quindi non posso essermi auto mandato un messaggio
      - Contro
        
        In Ogni sua variante non garantisce la segretezza
        
        il messaggio è passato in chiaro
- - - - la rete che collega il server e il client è insicura
      - Kerberos dovrebbe essere in grado di scongiurare qualsiasi attacco
        
        la possibilità che qualche attacco vada a buon fine esiste
        
        per questo per garantire una migliore sicurezza sarebbe meglio utilizzarlo all'interno di un dominio controllato
  - - - vanno "Kerberizzate"
      - utilizza uno specifico protocollo
    - - Attacchi di deny of service sul server kerberos implica che il servizio di autenticazione non funzioni
      - Possibile replicazione dei server responsabili dall'autenticazione ma non è facile da mantenere
    - - Il tempo va sincronizzato in maniera coerente su tutto il domninio
      - I tiket devono avere una validità consona
        
        Non troppo breve per evitare che dei tiket validi siano ritenuti invalidi
        
        Non troppo lunga per evitare che possano effettuare attacchi
    - - Può supportare mediamente l'odine delle centinaia o migliaia di utenti
  - - - GSS-API
      - Simple Authentication and Security layer
- - - - Il client richiede le credenziali dal TGS per un servizio e le ottiene
        
        Richiedo e ottengo i TICKET
      - Il client comunica il TicketTGS al TGS per richiedere un TicketS per accedere ad un certo servizio, tale messaggio contiene anche un campo autenticator che permette di capire se il ticket presentato è valido o meno utilizzando anche il meccanismo dei timestamp
      - Il TGS risponde con il ticket per accedere al servizio opportunamente marcato temporalmente per avere un timeout di validità del ticket
    - - Il client presenta le credenziali ottenute nella fase 2 al server che eroga il servizio per accedervi
        
        Spendo i TIKET temporali per accedere ad un servizio
        
        Il client richiede al server di utilizzare un servizio presentandogli il ticket ricevuto nella fase 2
        
        Il server risponde con le informazioni per accedere al servizio
        
        Il server valida l'accesso al servizio in base alle sue politiche, non è detto che tutti gli user possano accedere a tutti i servizi
        
        I tiket sono riutilizzabili per accedere ad altri servizi fino a che sono validi temporalmente, poi andrà richiesto attraverso le precedenti fasi
    - - Il Client richiede la chiave di sessione per la comunicazione con il TGS e la riceve
      - Il client inizia la comunicazione verso l'AS, mandando un messaggio contenente le varie informazioni, alcune di queste crittografate con la chiave statica ( TIME )
      - L'AS verifica che il client sia autenticabile e in caso positivo restituisce un messaggio contenente il TicketTGS ( crittografato con la chiave del TGS in modo che non possa essere letto se non dal TGS) e la chiave di sessione per avviare una comunicazione sicura con il TGS, la parte del messaggio che contiene questa e altre informazioni confidenziali viene crittografata con la chiave statica tra client e AS
  - - - Si occupa dell'autenticazione vera e propria dell'utente
      - Inizialmente l'applicazione negozia l'identità con l'AS
      - L'AS fornisce delle credenziali di atutenticazione non corrompibii
    - - Permette di accedere ai vari servizi attraverso il meccanismo dei tiket
  - - - AS e Client
        
        ricavata applicando una funzione di hash alla password ( ovviamente riferito ad un realm)
      - TGS e Server
      - AS e TGS
  - - - Tra TGS e Client
      - Tra TGS e Server
- - - - Si occupa di un certo realm
      - Ogni principal condivide una chiave con il KDC
        
        Il KDC si occupa dell'autenticazione tra i vari principal ( di norma uno fornisce un servizio e l'altro lo richiede )
        
        Non vi è scambio di password tra client e server, ma solo con la terza parte quindi si mantiene una segretezza reciproca
    - - Struttura del nome
        
        Primary/istance@NOMEREALM
        
        primary= nome servizio utente
        
        Istance= Qualifica dell'utente
    - - Rappresenta il domino
      - componenti
        
        Client
        
        Fornitori di servizi
        
        principal
        
        Server Kerberos (KDC)