Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό...

Ιόνιο ΠανεπιστήμιοΤμήμα ΠληροφορικήςΑκαδημαϊκό Έτος 2012-2013Εξάμηνο: Δ’

Ασφάλεια Υπολογιστών και Προστασία

Δεδομένων

Ενότητα Ε: Ασφάλεια Δικτύων:

Αυθεντικοποιημένη Εδραίωση Κλειδιού και

Εφαρμογές

Αυθεντικοποιημένη Εδραίωση ΚλειδιούSyllabus

1. Ασφαλής Επικοινωνία – Βασικές Έννοιες & Εργαλεία Αυθεντικοποίηση Χρήστη & Μηνύματος, Μυστικότητα

2. Κρυπτογραφικά Πρωτόκολλα Εδραίωσης Κλειδιού Ορισμοί-Κατηγοριοποίηση-Στόχοι Ασφάλειας

3. Εδραίωση Κλειδιού με Συμμετρικές Τεχνικές Διανομή, Μεταφορά, Συμφωνία Κλειδιού - Εφαρμογές

4. Εδραίωση Κλειδιού με Τεχνικές Δημόσιου Κλειδιού Μεταφορά, Συμφωνία Κλειδιού - Εφαρμογές

5. Προηγμένα Πρωτόκολλα Εδραίωσης

6. ΕφαρμογέςA. SSL/TLS (Secure Sockets Layer / Transport Layer Security)

B. SSH (Secure Shell)

C. IPSec (Internet Protocol Security)

ΠαθητικόςΕχθρό

ς

(Eve)

ΕνεργητικόςΕχθρ

ός

(Mallory)

1. Ασφαλής ΕπικοινωνίαΒασικές Έννοιες & Εργαλεία

Alice Bob

Ζητούμενο: Ασφαλής Επικοινωνία

H Alice & ο Bob μπορεί να είναι χρήστες,

Η/Υ, διεργασίες

κλπ…

Αυθεντικοποίηση Χρήστη:«Με ποιον μιλάω, τώρα?»Αυθεντικοποίηση Μηνύματος: «Ποιος δημιούργησε το μήνυμα που έλαβα?»Μυστικότητα (Εμπιστευτικότητα): «Κανείς δεν μπορεί να διαβάσει όσα λέμε εγώ και η Alice»

Αυθεντικοποίηση Χρήστη:«Με ποιον μιλάω, τώρα?»Αυθεντικοποίηση Μηνύματος: «Ποιος δημιούργησε το μήνυμα που έλαβα?»Μυστικότητα (Εμπιστευτικότητα): «Κανείς δεν μπορεί να διαβάσει όσα λέμε εγώ και η Alice»

1. Ασφαλής ΕπικοινωνίαΒασικές Έννοιες & Εργαλεία

Σήμερα, η κρυπτογραφία μας

προσφέρει ασφαλείς &

αποδοτικούς μηχανισμούς για

την εκπλήρωση των ιδιοτήτων

ασφάλειας:

ΠαθητικόςΕχθρό

ς

ΕνεργητικόςΕχθρ

ός

Alice Bob

Ζητούμενο: Ασφαλής Επικοινωνία

1. Τεχνικές Πρόκλησης-Απάντησης

2. Αυθεντικοποίηση με MAC (Αλγόριθμοι: MD5, SHA-1,…) & Ψηφιακές Υπογραφές (Αλγόριθμοι: DSA, RSA, ElGamal,… )

3. Συμμετρική Κρυπτογράφηση (Αλγόριθμοι: AES,3DES), Κρυπτογράφηση με Δημόσιο Kλειδί (Αλγόριθμοι: RSA, ElGamal,…)

Αυθεντικοποίηση Χρήστη:

«Με ποιον μιλάω, τώρα?»

Αυθεντικοποίηση Μηνύματος:

«Ποιος δημιούργησε το

μήνυμα που έλαβα?»

Μυστικότητα

(Εμπιστευτικότητα):

«Κανείς δεν μπορεί να

διαβάσει όσα λέμε εγώ και η

Alice»

Λόγω απόδοσης,

στην πράξη

προτιμώνται οι

συμμετρικές

τεχνικές !

2. Πρωτόκολλα Εδραίωσης ΚλειδιούΟρισμοί

Το πρόβλημα: Στις συμμετρικές

τεχνικές, η Alice και ο Bob

μοιράζονται ένα κλειδί Κ. Πώς

όμως αποκτούν αυτό το κλειδί;

Γενικότερη διατύπωση: Πώς δύο ή

περισσότερες οντότητες

αποκτούν από κοινού ένα μυστικό

(συμμετρικό) κλειδί για ασφαλή

επικοινωνία …

… δηλαδή έναντι παθητικών

ή/και ενεργητικών εχθρών

• Eve: Υποκλέπτει επικοινωνία

• Mallory: Επιθέσεις πλαστοπροσωπίας και ενδιάμεσης οντότητας

2. Πρωτόκολλα Εδραίωσης ΚλειδιούΟρισμοί

Σκοπός: Η εδραίωση ενός

εφήμερου ή «φρέσκου»

κλειδιού που αποκαλείται

κλειδί συνόδου (session

key)

Γιατί κλειδιά συνόδου;

1. Περιορισμός των συνεπειών αν ο «εχθρός» βρει ένα κλειδί.

2. Περιορισμός της ποσότητας υλικού που θα χρησιμοποιηθεί για κρυπτανάλυση.

3. Άρση ανάγκης αποθήκευσης πολλών κλειδιών για μεγάλο χρονικό διάστημα.

4. Ανεξαρτησία μεταξύ των συνόδων επικοινωνίας και των δικτυακών εφαρμογών

2. Πρωτόκολλα Εδραίωσης«Φυσική» Εδραίωση Κλειδιού

Σενάρια:

1. H Alice επιλέγει ένα κλειδί και το μεταδίδει στον Bob με φυσικό τρόπο

2. Μια Τρίτη Αρχή επιλέγει ένα κλειδί και το μεταδίδει στους Alice & Bob με φυσικό τρόπο Τα σενάρια 1 και 2,

συνήθως εφαρμόζονται για: Κρυπτογράφηση ζεύξης

(link encryption) στο

επίπεδο σύν-δεσης

δεδομένων (π.χ. Wi-fi)

Για κρυπτογράφηση από άκρη-σε-άκρη (end-to-end) στο επίπεδο δικτύου, όχι αποδοτικό N hosts: Ν(Ν-1)/2 κλειδιά

Τι θα γίνει αν η κρυπτογράφηση γίνει στο επίπεδο εφαρμογής; 1 κλειδί για κάθε ζεύγος

χρηστών ή διεργασιών; Case: Δίκτυο με

εκατοντάδες κόμβους & χιλιάδες διεργασίες!

2. Πρωτόκολλα Εδραίωσης«Φυσική» Εδραίωση Κλειδιού

2. (Λογική) Εδραίωση ΚλειδιούΚατηγοριοποίηση

Τρεις περιπτώσεις:

1. Οι Alice & Bob μοιράζονται

ήδη ένα κλειδί μακράς

διαρκείας (π.χ. password)


ξεχωριστά κλειδιά μακράς

διαρκείας με ένα έμπιστο

κέντρο (KDC).

3. Η Alice και ο Bob δεν

μοιράζονται κάποιο κλειδί

ΣΥΜΜΕΤΡΙΚΕΣ ΤΕΧΝΙΚΕΣ

ΤΕΧΝΙΚΕΣ ΔΗΜΟΣΙΟΥ ΚΛΕΙΔΙΟΥ

2. (Λογική) Εδραίωση ΚλειδιούΚατηγοριοποίηση

Τρεις περιπτώσεις:

1. Οι Alice & Bob

μοιράζονται ήδη ένα

κλειδί μακράς διαρκείας

(π.χ. password)


ξεχωριστά κλειδιά μακράς

διαρκείας με ένα έμπιστο

κέντρο (KDC).

3. Η Alice και ο Bob δεν

μοιράζονται κάποιο κλειδί

Σε κλειστά ή/και αυτόνομα συστήματα, τα κλειδιά μακράς διαρκείας (Master keys) χρησιμοποιούνται για την εδραίωση των (εφήμερων) κλειστών συνόδου. Τα Master keys διανέμονται με μη κρυπτογραφικό τρόπο (π.χ. φυσικά)

Η προτεινόμενη μέθοδος για συστήματα μεγάλης κλίμακας (π.χ. Internet)

2. Πρωτόκολλα Εδραίωσης ΚλειδιούΚατηγοριοποίηση

1. Πρωτόκολλα Διανομής

Κλειδιού (Key Distribution) Μια έμπιστη οντότητα (KDC)

δημιουργεί το κλειδί και το

στέλνει στην Alice και τον

Bob

2. Πρωτόκολλα Μεταφοράς

Κλειδιού (Key transport) Η Alice (Bob) δημιουργεί

ένα κλειδί και το στέλνει

στον Bob (Alice)

3. Πρωτόκολλα Συμφωνίας Κλειδιού

(Key Agreement) Η Alice & Bob συνεισφέρουν από κοινού

στη δημιουργία του κλειδιού συνόδου

2. Πρωτόκολλα Εδραίωσης Κλειδιού Κατηγοριοποίηση

Κρυπτογραφικά Πρωτόκολλα Εδραίωσης Κλειδιού

1. Συμμετρικές Τεχνικές2. Τεχνικές Δημόσιου Κλειδιού

Διανομής: Π1-Π8

Διανομής: Π1-Π8

Μεταφοράς: Π9-Π10


Συμφωνίας: Π11-Π12Συμφωνίας: Π11-Π12



Συμφωνίας: Π19-Π26Συμφωνίας: Π19-Π26

Πηγή: (Magkos et al, 2011)

2. Πρωτόκολλα Εδραίωσης ΚλειδιούΚατηγοριοποίηση

Σημείωση: Στις

συμμετρικές τεχνικές,

μπορούμε να

εντάξουμε μια

επιπλέον κατηγορία

4. Εδραίωση χωρίς

σύνδεση με προ-

μοιρασμένα κλειδιά

(Offline Key

Establishment with

Pre-Shared Keys)

K K

Session 1: Κ1 = Hash(K, n1)Session 2: Κ2 = Hash(K, n2)

Session j: Κj = Hash(K, nj)

…

Παράδειγμα (για j συνόδους)

n: nonce (number used

once)

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Ασφάλειας

1. Αυθεντικοποίηση Χρήστη (User Authentication)

2. Αυθεντικοποίηση Κλειδιού (Key Authentication)

A. Εννούμενη Αυθεντικοποίηση (Implicit Key Authentication)

B. Ρητή Αυθεντικοποίηση (Explicit Key Authentication)

3. Μυστικότητα Κλειδιού (Key Secrecy)

4. Φρεσκάδα Κλειδιού (Key Freshness)

Η αυθεντικοποίηση μπορεί να είναι μονόδρομη ή αμοιβαία

… ένα πρωτόκολλο εδραίωσης θεωρείται ασφαλές αν το κλειδίπου θα προκύψει είναι

ανέφικτο να το γνωρίζει/μάθει ένας

μη εξουσιοδοτημένος χρήστης…


2. Αυθεντικοποίηση Kλειδιού.

Ο χρήστης γνωρίζει την

ταυτότητα του χρήστη με

τον οποίο εδραίωσε το

κλειδί

A. Εννούμενη Αυθεντικοποίηση

π.χ. η Alice γνωρίζει ότι

μόνον ο Βob μπορεί να έχει

πρόσβαση στο κλειδί που

εδραιώνεται

B. Ρητή αυθεντικοποίηση

π.χ. η Alice βεβαιώνεται

ότι ο Βοb έχει πρόσβαση

στο κλειδί που εδραιώθηκε

1. Αυθεντικοποίηση

Χρήστη Κάθε χρήστης

μπορεί να καθορίσει:

A. Την ταυτότητα του

χρήστη με τον οποίο

εδραιώνει το κλειδί

συνόδου, και

B. ότι ο έτερος χρήστης

είναι ενεργός τη στιγμή

που εκτελείται το

πρωτόκολλοΓνωστή και ως «Επιβεβαίωση

Κλειδιού»


3. Μυστικότητα Κλειδιού

Μόνον οι

εξουσιοδοτημένοι χρήστες

έχουν πρόσβαση στο κλειδί

συνόδου

4. Φρεσκάδα Κλειδιού

Το εδραιωμένο κλειδί

πρέπει να είναι καινούριο,

δηλ. να μην έχει εδραιωθεί

ξανά στο παρελθόν από

άλλους χρήστες

2. Πρωτόκολλα Εδραίωσης Κλειδιού Στόχοι Αποδοτικότητας

Ένα πρωτόκολλο εδραίωσης πρέπει να

είναι αποδοτικό ως προς τις εξής

πολυπλοκότητες:

Carol

Bob

Alice

1. Επικοινωνία: Ο αριθμός των αποστολών

μηνυμάτων (passes),

Ο αριθμός των bit που

ανταλλάσσονται (per pass),

2. Υπολογισμοί: ο αριθμός των

απαιτούμενων υπολογιστικών πράξεων

3. Αποθήκευση: O απαιτούμενος

αποθηκευτικός χώρος που απαιτείται

για την εδραίωση

Συμβολισμοί

3. Εδραίωση με Συμμετρικές Τεχνικές3.Α. Διανομή Κλειδιού - Πρωτόκολλο Π1

Πρωτόκολλο Π1 - Απλή διανομή κλειδιού [38][Popek and Kline, 1979]


Πρωτόκολλο Π2 - Απλή διανομή με ρητή αυθεντικοποίηση


Επίθεση Ε1 - Μία επίθεση πλαστοπροσωπίας στο πρωτόκολλο Π2 [30]


Πρωτόκολλο Π3 -Αυθεντικοποίηση με εισαγωγή πληροφορίας σχετικής με την ταυτότητα των χρηστών [30]


Επίθεση Ε2 - Μία επίθεση πλαστοπροσωπίας στο πρωτόκολλο Π3 [30]


Πρωτόκολλο Π4 - Το πρωτόκολλο διανομής των Needham-Schroeder [35]( Needham and Schroeder, 1978)


Επίθεση Ε3 - Μία επίθεση πλαστοπροσωπίας στο Needham-Schroeder [14](Denning and Sako, 1981)


Πρωτόκολλο Π5 - Εισαγωγή χρονοσφραγίδων στο πρωτόκολλο Needham-Schroeder [14](Denning and Sako, 1981, Denning, 1981)

Menezes, Oorschot, Vanstone,

Handbook of Applied

Cryptography, CRC, 2001

Το Σύστημα Kerberos

Η Emily έρχεται στη δουλειά. Εισάγει σε

μια φόρμα το username και τον

κωδικό της πρόσβασης, στις 8.00

A.M

To λογισμικό Kerberos στον Η/Υ της Emily στέλνει το username στην

Υπηρεσία Αυθεντικοποίησης (AS) στον server KDC, που με τη σειρά της

επιστρέφει στην Emily ένα Εισιτήριο Έκδοσης Εsισιτηρίων (Ticket Granting

Ticket – TGT), κρυπτογραφημένο (συμμετρικά) με το password της

Emily

Όταν η Emily θελήσει να επικοινωνήσει με τον file server, το Kerberos στον

Η/Υ της στέλνει μια αίτηση, μαζί με το TGT, στην Υπηρεσία Έκδοσης Εισιτηρίων (Τicket

Granting Service – TGS) στον KDC.

Το Kerberos εξάγει το κλειδί συνόδου, και

αποστέλλει το εισιτήριο στον file

server για να αρχίσει η επικοινωνία !

Η TGS δημιουργεί και στέλνει στην Emily ένα

2o εισιτήριο, για την ταυτοποίηση της στον file

server. To εισιτήριο περιέχει ένα κλειδί

συνόδου , κρυπτογραφημένο με τα κλειδιά που μοιράζεται το KDC με Emily & τον

server

Αν η Emily έχει δώσει το σωστό password,

το TGT αποκρυπτογραφείται και η Alice αποκτά

πρόσβαση στο σταθμό εργασίας της

Εφαρμογή Νο 2The Kerberos System

The problem :

”In an open distributed environment users at workstations

wish to access services on servers distributed throughout the

network. The servers must be able to restrict access to

authorized users and to authenticate requests for service.”

A workstation cannot be trusted to identify users correctly A user may gain access to a particular workstation and pretend

to be another user operating from that workstation

A user may alter the network address of a workstation and thus

impersonate another workstation

A user may eavesdrop on exchanges and use a replay attack to

gain entrance to a server

(Steiner et al, 1988)

(Stallings, 2010)


In a distributed architecture consisting of clients and servers

three approaches to security can be envisioned:

1. Rely on each client workstation to assure the identity of its users

and rely on each server to enforce security policy based on user

identification (ID).

2. Require that client systems authenticate themselves to servers,

but trust the client systems concerning the identity of the user.

3. Require the user to prove identity for each service invoked.

Require that servers prove their identity to clients.

Third approach is supported by Kerberos:

(Stallings, 2010)


(Stallings, 2010)

A trusted, centralized auth.

server who facilitates

authentication of users to

servers and servers to users.

There are two versions Version 4

is still in common use

Version 5 (1994)

corrects some

deficiencies of version 4

Kerberos relies exclusively on

conventional encryption.

(Steiner et al, 1988, Miller et al,1988)

(Kohl et al, 1994)

(RFC 4120)


The following requirements were listed for Kerberos:

1. Secure: a network eavesdropper should not be able to obtain the

required information for impersonating a user.

2. Reliable: Kerberos should employ a distributed server architecture

with one system able to back up another.

3. Transparent: the user should not be aware that authentication is

taking place, except for the entering of the password.

4. Scalable: the system should have a modular, distributed

architecture to support large number of clients and servers.

(Stallings, 2010)

Kerberos Version 4

We build up to full protocol

A Simple Authentication Protocol This protocol uses an authentication server (AS) that knows the

passwords of each user and shares a secret key with each server.

Some issues: Plaintext transmission of password

Number of password uses

(Stallings, 2010)


(Bryant et al,1988)

C = ClientAS = authentication serverV = serverIDC = identifier of user on CIDV = identifier of VPC = password of user on CADC = network address of CKV= secret encryption key shared by AS and V

C AS: IDC|| PC || IDV

AS C: IDC || Ticket

CV: Ticket

Ticket = E(KV, [IDC|| ADC || IDV])

C AS: IDC|| PC || IDV

AS C: IDC || Ticket

CV: Ticket

Ticket = E(KV, [IDC|| ADC || IDV])

Kerberos Version 4

A More Secure Authentication Dialogue

(Stallings, 2010)


Once per user logon session:

(1) C AS: IDC || IDtgs

(2) AS C: E(KC, Tickettgs)

Once per type of service:

(3) C TGS: IDC || IDV || Tickettgs

(4) TGSC: TicketV

Once per service session:

(5) CV: IDC || TicketV

Once per user logon session:

(1) C AS: IDC || IDtgs

(2) AS C: E(KC, Tickettgs)

Once per type of service:

(3) C TGS: IDC || IDV || Tickettgs

(4) TGSC: TicketV

Once per service session:

(5) CV: IDC || TicketV

Tickettgs = E(Ktgs, [IDC|| ADC || IDtgs || TS1 || Lifetime1] )

TicketV = E(KV, [IDC|| ADC || IDV || TS2 || Lifetime2])

Tickettgs = E(Ktgs, [IDC|| ADC || IDtgs || TS1 || Lifetime1] )

TicketV = E(KV, [IDC|| ADC || IDV || TS2 || Lifetime2])

Issues Replays after C logs off

& before lifetime is over

Servers do not

authenticate to Users

Kc = key derived from user passwordTickettgs= Ticket granting ticketTicketv= Service- granting ticketTS = A time-stamp

Kerberos Version 4

The Version 4 Authentication Dialogue

(Stallings, 2010)


(Stallings, 2010)

Scalability of KerberosKerberos Realms and Multiple Kerberi

A Kerberos realm, is a full-service environment consisting

of a Kerberos server, a number of clients and app servers:

1. The Kerberos server has the IDs and hashed passwords of all

users. All users are registered with the Kerberos server.

2. The Kerberos server shares a secret key with each server. All

servers are registered with the Kerberos server.

Kerberos supports inter-realm authentication. Extra req:

3. The Kerberos server in each interoperation realm shares a

secret key with the server in the other realm. The two

kerberos servers are registered with the each other..

Kerberos & Τομείς Ασφάλειας (Security Domains)

Τομέας Ασφάλειας

Μία λογική (logical)

Ομάδα από υποκείμενα

και αντικείμενα

(χρήστες, Η/Υ, συσκευές,

προγράμματα &

εφαρμογές, δεδομένα,

… )

…που υπακούν σε ένα

κοινό σύνολο κανόνων

ασφάλειας (i.e., πολιτική

ασφάλειας)

Kerberos: Ο ελεγκτής

τομέα συγκεντρώνει

τους ρόλους AS και TGS

Τομείς Ασφάλειας (Security Domains)

Οι χρήστες (clients),

γίνονται μέλη στον τομέα

κάνοντας log on, με

διαδικασίες SSO

Μέσω LAN, WAN, VPN κλπ

Για κάθε τομέα, υπάρχει ένας

server (Domain Controller) όπου: Μια κεντρική ΒΔ (Ενεργός

Κατάλογος - Active Directory)

περιέχει τους λογαριασμούς &

ομάδες χρηστών και Η/Υ

Δημιουργούνται & επιβάλλονται

οι Πολιτικές Ασφάλειας του τομέα Πολιτικές ομάδων (group

policies)

Κριτήρια & Δικαιώματα

πρόσβασης

Ρυθμίσεις ασφάλειας

Αρχιτεκτονική Client-

Server

Λογική σύνδεση

Τομείς Ασφάλειας (Security Domains) -

Τομείς Ασφάλειας (Security Domains)

Μεγάλα συστήματα,

συχνά οργανώνονται

ιεραρχικά:

1. Δένδρο

Πολλοί Τομείς,

με το ίδιο

namespace

1. Δάσος (Forrest)

Πολλά δένδρα,

με διαφορετικά

namespaces

http://technet.microsoft.com/


Πρωτόκολλο Π6 - Το πρωτόκολλο διανομής των Otway-Rees [37](Otway and Rees, 1987)


Πρωτόκολλο Π7 - Το πρωτόκολλο Π6 με αμοιβαία αυθεντικοποίηση [33]


Πρωτόκολλο Π8 - Το πρωτόκολλο των Bellare-Rogaway [5](Bellare and Rogaway, 1995)

3. Εδραίωση με Συμμετρικές Τεχνικές3.Α. Διανομή Κλειδιού - Πλεονεκτήματα & Μειονεκτήματα

Μειονεκτήματα Αρχιτεκτονικής Υψηλή εμπιστοσύνη στον Trent Υψηλός φόρτος για τον Trent

Πλεονεκτήματα Αρχιτεκτονικής Εύκολη διαχείριση συστήματος Κάθε οντότητα αποθηκεύει ένα

μόνον κλειδί μακράς διαρκείας

3. Εδραίωση με Συμμετρικές Τεχνικές3.Β. Μεταφορά Κλειδιού - Πρωτόκολλο Π9

Πρωτόκολλο Π9 - Απλή μεταφορά κλειδιού [22](ISO/IEC 11770-2:1996)

3. Εδραίωση με Συμμετρικές Τεχνικές3.Β. Μεταφορά Κλειδιού - Πρωτόκολλο Π10

Πρωτόκολλο Π10 - Απλή μεταφορά κλειδιού με πρόκληση-απάντηση [33]

3. Εδραίωση με Συμμετρικές Τεχνικές3.C. Συμφωνία Κλειδιού - Πρωτόκολλο Π11

Πρωτόκολλο Π11 -To πρωτόκολλο ΑΚΕP2 [4]

ΚS = Hash(K’AB, NA, NB)

(Bellare and Rogaway, 1993)


Πρωτόκολλο Π12 - Συμφωνία κλειδιού με χρονοσφραγίδες

ΚS = Hash(kA, kB)


Πρωτόκολλο Π13 - Συμφωνία κλειδιού με πρόκληση-απάντηση

1. Η Alice φτιάχνει μια ΒΔ με 1.000.000 κλειδιά και αντίστοιχους (μοναδικούς) σειριακούς αριθμούς

2. Η Alice κρυπτογραφεί κάθε ζεύγος της ΒΔ με διαφορετικά κλειδιά μικρού μήκους (π.χ 20 bit)

4. Εδραίωση με Ασύμμετρες Τεχνικές4.Α. Μεταφορά Κλειδιού - Η ιδέα του Merkle

Τυχαία σειρά

(Merkle, 1978)

3. Η Alice στέλνει στον Bob

1.000.000 κρυπτογραφημένα

μηνύματα

4. Ο Bob επιλέγει στην τύχη ένα

μήνυμα και εξαπολύει μια

επίθεση brute force

π.χ. 1 ώρας διάρκεια

5. O Bob ανακτά π.χ. το ζεύγος

(1yt8a42x35 | 500,121)

6. O Bob επικοινωνεί με την Alice:

της λέει να χρησιμοποιήσει το

κλειδί που αντιστοιχεί στο

500.121

Η Eve δεν ξέρει πιο από τα κρυπτογραφημένα μηνύματα περιέχει το κλειδί που επέλεξε ο Bob !!

Η Eve θα πρέπει να «σπάσει» κατά μέσο όρο 219 ~ 500.000 μηνύματα !!!

π.χ. 500.000 ώρες εργασίας

!

!

Ασυμμετρία

4. Εδραίωση με Ασύμμετρες Τεχνικές4.Α. Μεταφορά Κλειδιού - Η ιδέα του Merkle (Merkle, 1978)

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού4.Α. Μεταφορά Κλειδιού - Πρωτόκολλο Π15

Πρωτόκολλο Π15 -Ένα απλό πρωτόκολλο μεταφοράς κλειδιού [39,33](Merkle, 1979,Kohnfelder 1978, p.5)


Στην απλή του μορφή το

Π15 είναι ευπαθές σε

επιθέσεις MITM(Rivest & Shamir, 1984)

Εφαρμογή Νο 3SSL 3.0 (Secure Sockets Layer)

… NA

… NB , SigCA(PKB)

EPKB[ΚΑ]

ΚS = Hash(KA, NA, NB) ΚS = Hash(KA, NA, NB)

Το ΔΚ της CA είναι πιθανώς προ-

εγκατεστημένο, κατά την

εγκατάσταση του λογισμικού πλοήγησης

Pre-master Secret Master SecretMaster Secret

O “διάδοχος” του SSLTLS (Transport Layer Security)

… NA

… NB , SigCA(PKB)

SigA(EPKB[ΚΑ],…), SigCA(PKA)

ΚS = Hash(KA, NA, NB) ΚS = Hash(KA, NA, NB)

Εφαρμογή Νο 4 Κινητή Τηλεφωνία: WAP & WTLS

Internet

Gateway

Web Server

WTLS SSL

Εφαρμογή Νο 5 ΙΕΕΕ 802.11i (Ασύρματα Τοπικά Δίκτυα)

Εδραίωση Κλειδιού σε WLANS (EAP-TLS)

Mobile client

Radius Authenticatio

n ServerEnterprise network

Enterprise network


Πρωτόκολλο Π16 -Μεταφορά κλειδιού με αυθεντικοποίηση οντότητας [23]


Πρωτόκολλο Π17 -Μεταφορά κλειδιού με αυθεντικοποίηση οντότητας [23](ISO/IEC 11770-3, 1999)


Πρωτόκολλο Π18 -Μεταφορά κλειδιού με αμοιβαία αυθεντικοποίηση [33]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού4.B. Συμφωνία Κλειδιού - Πρωτόκολλο Π19

Πρωτόκολλο Π19-Συμφωνία κλειδιού με αμοιβαία αυθεντικοποίηση [35]

ΚS = Hash(kA, kB)

(Needham & Schroeder, 1978)


Πρωτόκολλο Π20 - Τροποποίηση του πρωτοκόλλου Π19 [33]


Πρωτόκολλο Π21 - Παραλλαγή του πρωτοκόλλου Needham-Schroeder [35](Needham & Schroeder, 1978)


Πρωτόκολλο Π22 - Μια απλοποίηση του Π21 [35] (Needham & Schroeder, 1978)


Επίθεση E4 - H επίθεση του Lowe στο πρωτόκολλο Π22 [30]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού4.B. Συμφωνία Κλειδιού - Πρωτόκολλο Diffie-Hellman

pgK ba rrS mod)(pgK ab rr

S mod)(

Πρωτόκολλο Π23 - Το πρωτόκολλο Diffie-Hellman [15]

Εφαρμογές: Ο αλγόριθμος και οι παραλλαγές του χρησιμοποιούνται

σήμερα ευρέως σε δημοφιλείς εφαρμογές: π.χ. IPSec, SSH, SSL/TLS, …

(Diffie &Hellman, 1976)

Κρυπτογραφία Δημόσιου ΚλειδιούTo Πρωτόκολλο Diffie-Hellman – Ένα παράδειγμα

ag

bg

bagk )(

abgk )(

41101 mod35

22101 mod36

6101 mod416 k

6101mod225 k

Όλες οι πράξεις γίνονται mod p

g και p: Παράμετροι συστήματος

ΓΝΩΣΤΕΣ ΣΕ ΟΛΟΥΣ

Παράμετροι συστήματος

p= 101, g=3

a=5

b=6

John Hershey.

Cryptography

Demystified. McGraw-Hill

Professional, 2003


Επίθεση E5 - Μία επίθεση ενδιάμεσης οντότητας (MITM) στο DH [30]

4. Εδραίωση με Τεχνικές Δημόσιου Κλειδιού4.B. Συμφωνία Κλειδιού - To Πρωτόκολλο STS [16]

Πρωτόκολλο Π24 - Το πρωτόκολλο Station to Station (STS) [16](Diffie et al, 1981)

, SigB(m1,m2), CertB

SigA(m1,m2), CertA

Εφαρμογή Νο 6: Virtual Private Networks (VPNs)IPSec - Το πρωτόκολλο IKE (Internet Key Exchange)

A, (ga mod p)

B, (gb mod p)

A B

m1

m2

Εφαρμογή Νο 7: Secure Shell (SSH)Εδραίωση Κλειδιού στο πρωτόκολλο SSH

SigB(m1,m2)

A, (ga mod p)

B, (gb mod p),

A B

m1

m2

Αυθεντικοποίηση χρήστη (π.χ. αποστολή password,

κρυπτογραφημένου με το Ks)

pgK abS mod pgK ba

S mod

Εφαρμογή Νο 7: Bluetooth v. 2.1Εδραίωση Κλειδιού στο Bluetooth

Elliptic Curve Diffie-Hellman (ECDH) Key Exchange

Let’s pair

Device A PKa

PKb

Device B

DHkeyA = aPKb

DHkeyB = bPKa

DHkeyA = aPKb = abG = baG = bPKa = DHkeyB

http://www.aladdin.com/blog/pdf/AndrewLindell-BlackHat08.ppt


Πρωτόκολλο Π25 - Το πρωτόκολλο εδραίωσης κλειδιού X.509 [34]


Πρωτόκολλο Π26 - Το πρωτόκολλο Π25 με πρόκληση-απάντηση [34]

5. Προηγμένα Πρωτόκολλα Εδραίωσης H Οικογένεια Πρωτοκόλλων MTI [31]

Πρωτόκολλο Π27 - To πρωτόκολλο συμφωνίας MTI/A0 [31] (Matsumoto et al, 1986)

5. Προηγμένα Πρωτόκολλα ΕδραίωσηςΤο πρωτόκολλο ΕΚΕ (Encrypted Key Exchange) [7]

Πρωτόκολλο Π29: Το πρωτόκολλο ΕΚΕ [7](Bellovin and Merritt, 1992)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Το πρωτόκολλο ΕΚΕ2 [3]

pgK barrS mod

Πρωτόκολλο Π30: Το πρωτόκολλο ΕΚΕ2 [3](Bellare et al, 2000)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Εδραίωση Κλειδιού Ομάδας στο DH

Carol

Bob

Πώς μπορούν 3 ή

περισσότεροι

χρήστες να

συμφωνήσουν σε

ένα κοινό κλειδί K

…

…

Χρησιμοποιώντας

το πρωτόκολλο

DH;

Group Key Agreement

Alice

Carol

(Ingemarsson et al, 1982)

5. Προηγμένα Πρωτόκολλα Εδραίωσης Εδραίωση Κλειδιού Ομάδας στο DH

Carol

Bob

Alice

Πώς μπορούν 3 ή

περισσότεροι

χρήστες να

συμφωνήσουν σε

ένα κοινό κλειδί K

…

…

Χρησιμοποιώντας

το πρωτόκολλο

DH;

Group Key Agreement

(Ingemarsson et al, 1982)

5. ΣυνοψίζονταςΣυμμετρικά Πρωτόκολλα vs Πρωτόκολλα ΔΚ

Εδραίωση με Συμμετρικά Συστήματα ΥΠΕΡ

1. Απόδοση (κόστος υπολογισμών, χωρητικότητας, αποθήκευσης)

ΚΑΤΑ

1. Απαιτούν προ-συμφωνημένα μυστι-κά (με άλλους κόμβους ή με το KDC) Διαχείριση κλειδιού σε συστήματα

μεγάλης κλίμακας: Δύσκολη Εφαρμογή σε κατανεμημένα και

δυναμικά περιβάλλοντα: Δύσκολη

2. Στα συστήματα διανομής, το KDC αποτελεί μοναδικό σημείο αποτυχίας

Εδραίωση με Συστήματα ΔΚ ΥΠΕΡ

1. Δεν απαιτούν την ύπαρξη προ-εγκατεστημένων μυστικών, ούτε ενός πλήρως έμπιστου, online KDC

2. Ιδανικά για συστήματα μεγάλης κλίμακας και δυναμικής τοπολογίας

3. Μη αποποίηση ευθύνης (ψηφιακές υπογραφές)

ΚΑΤΑ

1. Απόδοση (κόστος υπολογισμών, χωρητικότητας, αποθήκευσης)

2. Διαχείριση κλειδιού (Υποδομές δημόσιου κλειδιού- PKI)

Εφαρμογές

A Classification of Threats on the Web (Stallings, 2010) *

Relative Location of Security Facilities in the TCP/IP Protocol Stack

Ασφάλεια στο Επίπεδο Εφαρμογής (S/MIME, PGP, Kerberos,…) Σχεδιασμός εξειδικευμένων υπηρεσιών ασφάλειας (user-to-app)

Ασφάλεια στο Επίπεδο «above TCP» (SSH, SSL/TLS) Ασφάλεια “end-to-end” (app-to-app)

Ασφάλεια στο Επίπεδο IP (IPSec) Διαφάνεια, προστασία όλων των εφαρμογών, (host-to-host)

Ασφάλεια στο Επίπεδο MAC (Data Link) (WPA, IEEE 802.11i,…) “hop-by-hop” security; WLAN & Cellular security (NIC-to-NIC)

…

(Stallings, 2010),* (Katz, 2010)*

What Layer?

For most implementations of IP stacks Transport layer and below implemented in operating system. Above transport layer implemented in user process.

1. SSL/TLS (or SSH) OS doesn’t change, applications do.

2. IPsec: OS changes. Applications unchanged.

(Basin, 2005) * (Kaufman, 2002) *

Secure Socket Layer andTransport Layer Security

Goal: Reliable, end-to-end security

Best for: Connection-oriented

sessions

User: Users not necessarily involved

OS: Not necessarily modified

App: Easy to modify apps to use

SSL

Current version: SSL v3, also known

as TLS (Transport Layer Security): Internet Standard (RFC 5246)

(Katz, 2010)*(Stallings, 2010),*

*

SSL Record Protocol

SSL Record provides two services

for SSL connections: Confidentiality: Handshake defines a

shared key for encrypting SSL payloads

Message Integrity: Handshake

defines a shared key for MAC

(Stallings, 2010) *

SSL Handshake Protocol (Stallings, 2010)*


Phase 1. Establish Security Capabilities

Key exchange method (cipher suite)

1. RSA key transfer: session key

encryp-ted with receiver’s PK (cert is

available)

2. Fixed Diffie-Hellman: Cert contains

DH public-key (fixed key) signed by

CA

3. Ephemeral Diffie-Hellman: sign (RSA

or DSS) & send ephemeral DH keys

4. Anonymous Diffie-Hellman: Use the

base DH key agreement algorithm


Phase 2. Server Auth and Key Exchange Cert not required for anonymous DH Server_key_exchange not required if:

1. Fixed DH (cert already contains key)

2. RSA key transfer is to be used

Server_key_exchange may be needed in:

1. Anonymous DH: Send global values (p, g) and the server’s public DH key

2. Ephemeral DH: the values above, signed with server’s private key

3. RSA key transfer in which the server has a signature-only RSA key: Server creates a temporary key pair,

then signs & sends pk (exponent & modulus)

Signature also contains nonces so far:


Phase 3. Client Auth and Key Exchange Server may also ask a client cert

(TLS) Content of client_key_exchange:

1. RSA key transfer: Client generates a 48-byte pre_master_secret & encrypts with server’s public key

2. Ephemeral or Anonymous DH: The client’s public DH parameters

3. Fixed DH: content null (DH parameters were sent in the certificate message)

Certificate_verify is sent only if client’s cert has a signing capability:

Goal: prove possession of private key


Phase 4. Finish

Completion of setting up a

connection

Finished message verifies that auth

and key exchange were successful Concatenation of two hashes:


Master Secret Creation

It is built upon a pre_master_secret,

which, has already been built in 2

ways:

1. RSA key transfer: pre_master is sent

by client, encrypted with server’s pk

2. Diffie-Hellman: pre_master_secret is

the established DH key

Both sides now compute

master_secret:

In TLS, master_secret is computed as:


Generation of Cryptographic Parameters

CipherSpecs requires: A client write MAC secret

A server write MAC secret

A client write key and IV

A server write key and IV

How? Hash master_secret until enough

output is generated:

Transport Layer Security (RFC 5246) (Stallings, 2010)**

Similar to SSLv3 with minor differences record format version number

uses HMAC for MAC

a different pseudo-random function

has additional alert codes

some changes in supported ciphers

changes in certificate types & negotiations

changes in crypto computations & padding

(Brown, 2011)*

Transport Layer Security (RFC 5246) (Stallings, 2010)**

HTTP Secure (HTTPS)HTTP over SSL/TLS

Motivation

HTTP: subject to man-in-the-

middle and eavesdropping

attacks

Goal

Encrypted communication &

iden-tification of (at least) Web

server over an insecure network

Solution

Use ordinary HTTP over an

SSL/TLS connection Documented in RFC 2818

HTTPS: a URI scheme URLs begin with https://

Use port 443

Used in: Payment transactions

User access with passwords

Secure mail,

Corporate Intranet,…

(Stallings, 2010)* (Brown, 2011)*

https://www.owasp.org/index.php/Man-in-the-middle_attack

*

*

HTTP Secure (HTTPS)HTTP over SSL/TLS (Stallings, 2010)* (Brown, 2011)*

The attacker can only know the fact that a connection takes place between two hosts with known domain names and IP addresses

The attacker can only know the fact that a connection takes place between two hosts with known domain names and IP addresses

Information that HTTPS encrypts: URL, document contents, form data, cookies, HTTP headers

Information that HTTPS encrypts: URL, document contents, form data, cookies, HTTP headers

HTTP Secure (HTTPS)HTTP over SSL/TLS(Stallings, 2010)*

Other Issues Certificate revocability

Browser should check whether a cert is still valid

Implement Online Certificate Status Protocol (OCSP)

Software security issues (Browser and Server)

Client Authentication

HTTPS can also be used for

controlling access to a web

server Admin builds a cert for each

user

Each user loads cert to browser

Typically, the certificate

contains name and e-mail

address of user

(RFC 2560)*

*, *

Εφαρμογές Κινητή Τηλεφωνία: WAP & WTLS

Internet

Gateway

Web Server

WTLS SSL

Εφαρμογές ΙΕΕΕ 802.11i (Ασύρματα Τοπικά Δίκτυα)

Εδραίωση Κλειδιού σε WLANS

(EAP-TLS)

Mobile client

Radius Authenticatio

n ServerEnterprise network

Enterprise network

Current version: SSH2

(RFCs 4250-

4256)

Secure Shell (SSH)

Initial version (SSH1) to replace TELNET & other insecure schemes

Today, SSH provides a general client-server capability

Remote login, file transfer, mail,…

(Stallings, 2010)

*

*

Motivation: (old) Telnet sessions are unencrypted !Motivation: (old) Telnet sessions are unencrypted !http://www.ibm.com/developerworks/aix/library/au-sshsecurity/

*

Secure Shell (SSH)Transport Layer Protocol

A. Host Keys

Server auth occurs here Server possesses public/private

key pair

Client must have a priori

knowledge of the server’s public

host key

Two alternative trust models:

1. Client has a local database that

associates a host name with a

pk

2. Host name-to-key certified by a

CA (client knows CA’s root key)

*

*

*

*


B. Packet Exchange

(Stallings, 2010)

*

*

*


B. Packet Exchange

(Stallings, 2010)

*

*

Steps of SSH Transport Layer

1. Identification string exchange These strings are used in the DH

key exchange later

2. Algorithm negotiation Key exchange, encryption, MAC,

compression

3. Key exchange Diffie-Hellman key exchange

*


(Stallings, 2010)

*

*

*

Secure Shell (SSH)Transport Layer Protocol – DH Key Exchange

(Stallings, 2010)

*

*

*


(Stallings, 2010)

*

*

Subsequent to DH key

exchange, all data is exchanged

as the pay-load of an SSH

packet, protected by encryption

and MAC

C. Key Generation

All needed keying material is

gene-rated from established DH

key:

*

Three authentication methods:

1. Public-key: Client sends a public

key and a signature on a message

Typically , user supplies a pass-

phrase to decrypt signature

key

2. Password: Client sends password,

encrypted by TLP

3. Host-based: Host locally authenti-

cates (multiple) user(s), then signs

a message with host’s private key

Secure Shell (SSH)User Authentication Protocol

(Stallings, 2010)*

*

Secure Shell (SSH)Connection Protocol

Assumes a secure authenti-

cation connection (tunnel)

Uses the tunnel to multiplex

a number of logical channels

All types of SSH communica-

tion use separate channels Either side may open a

channel with unique id

number

Channels are flow controlled

using a window mechanism

(Stallings, 2010)*

*

http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm


(Stallings, 2010)*

*

Life of a channel has 3

stages:

1. Opening a channel,

2. Data transfer,

3. Closing a channel


(Stallings, 2010)*

*

Channel types:

1. Session Remote execution of a program

(shell, file transfer, mail, …)

2. Local port forwarding SSH client “listens” and

intercepts selected app-level

traffic and redirects it to SSH

tunnel

Examples: POP3, SMTP, HTTP,…

3. Remote port forwarding Tunnel initiated on server side,

goes back through client

machinePort forwarding services are also known as SSH tunneling

Port forwarding services are also known as SSH tunneling

*

Secure Shell (SSH)Local Port Forwarding

(Stallings, 2010)*

*

Case: Use a local mail client to get mail from mailserver via POP3

Case: Use a local mail client to get mail from mailserver via POP3

Unprotected session

*, *, *

Secure Shell (SSH)Remote Port Forwarding

(Stallings, 2010)*

*, *,

Case: You wish to access a server at work from home (server is behind a firewall)

Case: You wish to access a server at work from home (server is behind a firewall)*

Internet Protocol Security (IPsec)

Motivation

An enterprise can run a

secure, private network over

Internet

1. Encrypt packets that

leave/enter the premises

2. Authenticate packets that

leave/enter the premises

Security at the IP level

Protect all apps (with or

without security

mechanisms!)

Transparent to end users

(Stallings, 2010)*

IPsec (Stallings, 2010)*

Applications of IPsec

1. Branch connectivity Company builds a secure VPN

over Internet or public WAN

2. Secure remote access User calls local ISP & gains

secure access to company network

3. Extranet & Intranet connectivity Secure communication with

other organizations and/or other depart-ments within enterprise

•http://www.digi-cube.com/images/client2network_vpn.gif

IPsec (Stallings, 2010)*

Rooting Applications

IPsec can assure that: A router advertisement comes

from an authorized router

A neighbor advertisement

comes from an authorized router

A redirect message comes from

a router to which packet was

sent

A routing update is not forged

(Stallings, 1996)*

*

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

To πρότυπο IPsec

IPsec Services Access Control

Connectionless integrity

Data origin authentication

Rejection of replay packets

Confidentiality

Traffic flow confidentiality

Two (2) protocols are used:

1. AH (Authentication Header) Authentication & Integrity

2. ESP (Encapsulation Sec. Payload)

Confidentiality (& optional authentication / integrity)

AH and ESP support two modes:

1. Transport mode Only protect IP packet payload

(protect upper layer protocol) Case: E2E between 2 hosts

2. Tunnel mode Protects the entire IP packet

Case: A number of endnodes (without IPsec installation) on networks between firewalls

Case2: endnode to firewall

(RFC 4301)*

(Stallings, 2010)*

(Heidari, 2004)*

*

*

To πρότυπο IPsec (Stallings, 2010)*

IPsec Architecture (Stallings, 2010)*

Encapsulating Security Payload (ESP)(Stallings, 2010)*

Encapsulating Security Payload (ESP)Transport and Tunnel mode (Stallings, 2010)*

ESPTransport and Tunnel modes

Transport mode Confidentiality &

integrity for any app

(no need to implement

confidentiality in an

app separately)

o Traffic analysis on

transmitted packets !

Tunnel mode Counter traffic analysis

Simplifies key

distribution

(Stallings, 2010)*

Encapsulating Security Payload (ESP)Transport and Tunnel mode (Stallings, 2010)*

IP Header ESP Header Payload (TCP, UDP, etc)

IP Header ESP Header Payload (TCP. UDP,etc)IP Header

Transport Packet layout

Tunnel Packet layoutΑπροστάτευτο Προστατευμένο

ESP & AH

Note: In transport mode, AH is better than ESP with authentication, since AH also provides integrity protection for some fields inside the IP header (although this can also be offered by ESP tunnel mode)

Note: In transport mode, AH is better than ESP with authentication, since AH also provides integrity protection for some fields inside the IP header (although this can also be offered by ESP tunnel mode)

Ipsec - Combining Security Associations (Stallings, 2010) *

IP SecurityIKE (Internet Key Exchange)

Goal Mutually authenticated

session key(s) establishment

Protocol A variarion of DH key

exchange with extra features

1. Cookies, to thwart clogging

2. Nonces to prevent replay

3. Mutual authentication, to thwart MITM attacks

4. Optional anonymity

Three authentication methods:

1. Public signatures keys. Sign

hashes of previous messages

2. Public encryption keys.

Encrypt challenges with

responder’s PK

3. Symmetric key encrypt. Use

an out-of-band established key

(Stallings, 2010) *

(RFC 4306) *

*

Cookie: a hash over IP (src, dest) addresses, UDP (src, dest) ports, & a locally generated secret value

Cookie: a hash over IP (src, dest) addresses, UDP (src, dest) ports, & a locally generated secret value

*

Clogging attacks Opponent forges legitimate IP & sends a public DH key to victim;

Victim performs modular exponentiation to compute the DH key;

Repeated messages of this type can clog the victim’s system with

useless work.

Suggestion: Cookies When receiving request from S, send cookie to S; start processing

after cookie comes back from the initiator

Stateless Cookies Responder does not have to remember cookies he sent out;

Cookie is a function of e.g., IP address and a secret known to

responder

Internet Key ExchangeClogging attacks & Cookies

(Stallings, 2010) *

(Sun, 2011) *

Internet Key ExchangeClogging attacks & Cookies

(Stallings, 2010) *

(Sun, 2011) *

IPSecCase: the Photuris Protocol (candidate for IKE)

{ } –encryption with the established DH key

(Kaufman, 2002) *

Anonymous DH with identity hiding and stateless cookies

IKE Phase 1Aggressive Mode

Proof I’m Bob/Alice:

(a) I prove I know the key associated to my identity (e.g., private signature key, private decryption key, pre-shared key)

(b) Integrity-protect the previous messages

(Kaufman, 2002) *

IKE Phase 1Main Mode

(Kaufman, 2002) *

+ cookies

IKE Phase 1Public Signature Keys, Main Mode

(Kaufman, 2002) *

IKE Phase 1Public Signature Keys, Aggressive Mode

(Kaufman, 2002) *

IKE Phase 1Public Encryption Keys, Main Mode, Original

(Kaufman, 2002) *

IKE Phase 1Public Encryption Keys, Aggressive Mode, Original

(Kaufman, 2002) *

IKE Phase 1Public Encryption Keys, Main Mode, Revised

(Kaufman, 2002) *

IKE Phase 1Public Encryption Keys, Aggressive Mode, Revised

(Kaufman, 2002) *

IKE Phase 1Pre-Shared Secret Keys, Main Mode

(Kaufman, 2002) *

IKE Phase 1Pre-Shared Secret Keys, Aggressive Mode

(Kaufman, 2002) *

IP SecurityCryptographic Suites

(Stallings, 2010) *

Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό...

Documents

Transcript of Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό...