TMC Projet 2015 2016

Master 2nde année
TMC
Projet
Échanges de messages sécurisés dans un réseau ad hoc de Raspberry Pi & nRF24L01
Contexte du projet
Développer un outil de communication sécurisé dans le cadre d’un réseau ad hoc :
⋆ utilisation du chiffrement asymétrique RSA avec des clés créées à partir d’une identité (IBE, « Identity
Based Encryption », basé sur la proposition de Jon Callas) ;
⋆ échange de messages chiffrés/authentifiés par radio « ultra low energy » : nRF24L01.
Décomposition fonctionnelle du projet
Sécurité
□ Gestion des identités sécurisées basée sur un IBE utilisant RSA :
⋄ embarqué sur chaque nœud ;
⋄ utilise un secret commun à tous les nœuds du réseau (secret du PKG) ;
⋄ utilise un PRNG pour la génération de la bi-clé RSA :
⋆ utilisation d’une « chaîne » de HMAC, dont la clé est le secret de l’IBE ;
⋆ le point de départ du PRNG est basé sur l’identité recherchée ;
⋆ utilisation du PRNG comme générateur aléatoire dans RSA pour la création des bi-clés.
□ échange sécurisé de A ⟹ B :
⋄ A récupère la clé publique de B auprès de l’IBE ;
⋄ A chiffre une clé de session AES à l’aide de la clé publique de B et l’envoi à B ;
⋄ A communique avec B par AES à l’aide de cette clé de session partagée ;
⋄ Les échanges doivent prendre en compte la nature de la couche physique : paquet de taille
restreinte, perte possible de paquet et authentification de l’émetteur des données : utilisation
du mode AES-GCM.
□
□
□
□
□
□
Radio
Communication Raspberry ⟺ nRF24L01 : bus SPI ;
Consommation : 40𝑚𝑤 (Wi-Fi 300𝑚𝑊 ) ;
bande de fréquences : ISM, « Industrial, Science & Medical » 2, 45𝐺𝐻𝑧 découpé en 126 canaux ;
codage des données : GFSK ;
puissance : limitée ;
MAC, « Medium Access Control », « est-ce que c’est pour moi ? » : « Shockburst ™ »
⋄ adressage ;
⋄ gestion des erreurs : CRC & acquittement, Retransmission ;
□ débit : 1𝑀𝑏𝑝𝑠 , 2𝑀𝑏𝑝𝑠 .
Protocole de communication
Couche 5 : application ⟶ ?
Couche 3 & 4 : protocole d’échange + IBE, message de de 32 octets, adresse de 5 octets ;
Couche 1 & 2 : nRF24L01 « Shockburst ™ ».
Gestion de la radio
□ choix du canal de communication : même canal ;
□ choix de l’émission/réception : l’émetteur transmets quant il le veut et on détecte les erreurs de la
couche 2 ⟶ réémission aléatoire ;
Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
1/6
Utilisation du PRNG Fortuna pour la génération de clés RSA
Pour utiliser le PRNG Fortuna :
#! /usr/bin/python
nom_destinataire = "[email protected]"
from Crypto.Random.Fortuna import FortunaGenerator
generateur=FortunaGenerator.AESGenerator()
generateur.reseed("toto")
generateur.key.encode('hex')
print generateur.pseudo_random_data(32).encode('hex')
Géneration des clés RSA à l’aide du PKG et vérification de leur reproductibilité
#!/bin/python
import subprocess
from Crypto.Hash import HMAC
from Crypto.Hash import SHA512
mon_hmac=HMAC.new(key="mon_secret",digestmod=SHA512)
mon_hmac.update("[email protected]")
IDT = mon_hmac.digest()
from Crypto.Random.Fortuna import FortunaGenerator
generateur=FortunaGenerator.AESGenerator()
generateur.reseed(IDT)
from Crypto.PublicKey import RSA
cle = RSA.generate(2048,randfunc=generateur.pseudo_random_data)
fic_cle = open("ma_cle1.pem","w")
fic_cle.write(cle.exportKey("PEM"))
fic_cle.close()
generateur=FortunaGenerator.AESGenerator()
generateur.reseed(IDT)
cle = RSA.generate(2048,randfunc=generateur.pseudo_random_data)
fic_cle = open("ma_cle2.pem","w")
fic_cle.write(cle.exportKey("PEM"))
fic_cle.close()
resultat = subprocess.check_output('diff ma_cle1.pem ma_cle2.pem',shell=True)
if resultat :
print "Cles differentes :\n",resultat
else :
print "Cles identiques"
Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
2/6
GCM
Utilisation dans le cadre du projet d’AES-GCM
Pour la construction du paquet avec chiffrement et authentification :
Header
Seq.
Data
IV
Plaintext
Addtl Auth Data
GCM Encryption
Header
Seq.
Ciphertext
Authentication Tag
Encrypted Data
ICV
GCM
Pour le 4:
déchiffrement
l’authentification
du paquet : a packet, showing how the fields of the security
Figure
Using GCMetto
encrypt and authenticate
encapsulation map onto the inputs and outputs of the authenticated encryption mode.
Header
Seq.
Encrypted Data
ICV
than the plaintext, and the decapsulation
halt and the plaintext
would be Tag
discarded rather
IV would Ciphertext
Authentication
than forwarded or further processed. After the operation, the header and sequence number can
Addtl Auth
Data
be checked, and their values
can be
trusted.
By including the sequence number in the IV,GCM
we Decryption
can satisfy the requirement that IV values be
unique. If that number is less than 96 bits long, it can be concatenated with another value in order
to form the IV. This other value could be constant, such as a string of zeros, or it could be a random
Plaintext it makes the inputs less predictable than
string, which adds to the security of the system because
they would be otherwise. The data needed to form the IV has to be known to both the encrypt
side and the decrypt
side, butSeq.
it need not all be included
Header
Data in the packet.
In some situations, it may be desirable to have the same GCM key used for encryption by more
Remarques
: Figure
5: case,
Usingcoordination
GCM to decrypt
and verify
the authenticity
of a packet.
than
one device.
In this
is needed
to ensure
the uniqueness
of the IV values. A
⋆
l’entête,
«
Header
»,
correspond
à
l’adresse
sur
5
octets
;
simple way in which this requirement can be met is to include a device-specific value in the IV,
⋆ lesasdonnées,
« Data
», correspond aux données sur 16 octets ;
such
a network
address.
tual property
restrictions.
These goals are important for high-speed network security, especially at
⋆ the
le ICV,
« Integrity Check Value », correspond à l’étiquette d’autentification calculée par AES-GCM,
link layer. This point is underscored by the fact that the IEEE 802.1 MAC Security Task Group
quiproposed
est au plustodeuse
16 mode
octets. as the standard’s mandatory-to-implement cryptoalgorithm [14].
has
⋆ on remarque que le numéro de séquence, « Seq. » ne peut être stocké dans le paquet qui est limité
6 Defining
and
Rationale
àProperties
32 octets
!
a mode
using generic composition (encrypt-then-authenticate [15]) is a simple way to
achieve
Solution
: a provably secure mode of operation, as long as the underlying components for encryption
and
authentication
areAuthentication
provably secure.
Ourpetite,
strategy,
similar
to that of
and: EAX, was to
▷ Passer
à une properties
taille d’«
» plus
parIts
exemple
surCWC
12 octets
The
important
of GCM aretag
summarized
incomme
Table 2.
primary
motivation
is the need
start with generic composition and then modify the algorithm in provably secure ways that better
foraddress
an authenticated
encryption
mode
that
can
be
efficiently
implemented
in
hardware
at very
Wikipedia
other requirements.
high data
rates,
achieves
high
performance
in
software,
is
provably
secure,
and
is
free
of
intellecThe authentication strength depends on the length of the authentication tag, as with all symmeCounter
mode is
the obviouscodes.
choiceHowever,
for the foundation
of anyauthentication
authenticated
encryption
tric message
authentication
the use of shorter
tags
with GCMmode,
is
since
it is the one
that isparameter.
fully parallelizable.
Our be
choice
discouraged.
Thewell-known
bit-length of encryption-only
the tag, denoted16
t, mode
is a security
In general, t may
any of
MAC
the best
solution
between
hardware
efficiency
(particularly,
onerepresents
of the following
fiveavailable
values: 128,
120, 112,
104, or
96. For certain
applications,
t mayparallelizbe 64
ability
and
requirements),
software
efficiency,
and
intellectual
property
or 32,
butmemory
the use of
these two tag lengths
constrains
thesecurity
length ofbound
the input
data
and the lifetime
restrictions.
of the key.Like CWC, we chose a parallelizable MAC based on the Carter-Wegman design [16]
thatAppendix
uses polynomial
However,
we guidance
used a binary
Galois
field rather
a 127-bit
C in NISThashing.
SP 800-38D
provides
for these
constraints
(for than
example,
if t =integer
32
fieldand
because
of
the
ease
and
efficiency
with
which
binary
fields
can
be
implemented
in
hardware.
the maximal packet size is 210 bytes, then the authentication decryption function should
be
Because
ourno
primary
motivation
is to
highthe
data
rates, the
choice
field
withthen
hardwareinvoked
more than
211 times;
if achieve
t = 64 and
maximal
packet
size of
is a215
bytes,
the
friendly multiplication operations is natural. Perhaps surprisingly, the binary field makes it easier
authentication decryption function should be invoked no more than 232 times).
to realize high-speed software implementations, as shown below.
In hardware, GCM adds a negligible amount of overhead compared to a pipelined AES implementation. OCB would share similar properties, except that it requires both an AES encryption and
AES decryption engine. CWC, on the other hand, has an expensive message authentication funcResp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
17
3/6
▷ Déterminer comment modifier la bibliothèque Python pour obtenir un « Authentication tag » sur 96bits ;
▷ consulter le draft du 28 juillet 2014 https://tools.ietf.org/html/draft-ietf-avtcore-srtp
-aes-gcm-14
In both CCM and GCM, the algorithm negotiation selects what tag size
is to be used.
In GCM, the authentication tag is simply truncated to
the appropriate length, but CCM requires that the tag length be an
explicitly input to the algorithm as the Tag_Size_Field.
Dans lequel on peut lire que le « tag » est simplement tronqué à la taille voulu (d’où une proposition
améliorée appelée « CWC Mode »).
On constate que la récupération de l’« authentication tag » est tronquée : seuls les 12 premiers octets sont
récupérés, puis comparés avec l’« authentication tag » caclulé en interne : si les 12 octets sont les mêmes
alors l’authentication est réussie !
Chiffrement et authentification des messages
Pour chiffrer et authentifier les messages que nous échangerons par l’intermédiaire du composant radio
nRF24L01, nous utiliserons :
▷ les messages transportés sont d’au plus 32 octets ;
▷ un chiffrement symétrique sur une taille de données suffisante : AES-128, soient des blocs de données
chiffrées de taille multiple de 16 octets ;
▷ une authentification de ces messages à l’aide d’un GMAC, « Galois Message Authentication Code »,
de taille limitée à 96bits ou 12 octets ;
▷ un champs « numéro de séquence » pour gérer la fragmentation/défragmentation des messages de taille
supérieure à celle d’un paquet.
12 octets
4 octets
12 octets
données chiffrées
num séq
« authentication tag »
Dans le cadre du projet, on considérera que l’IBE est en mode offline, embarqué dans un composant sécurisé comme une carte à puce, sur le TMC.
Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
4/6
Utilisation de la version béta de la bibliothèque PyCrypto incorporant AES-GCM
xterm
pef@samus:~/tmp/pycrypto-2.7a1$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Crypto
>>> print Crypto.__version__
2.7a1
>>> from Crypto.Cipher import AES
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='1',mac_len=8)
>>> (a,b)= cipher.encrypt_and_digest('bonjour')
>>> a.encode('hex')
'2b59499b904ed4'
>>> b.encode('hex')
'ab0656a30b8d846d'
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='1',mac_len=8)
>>> cipher.decrypt_and_verify(a,b)
'bonjour'
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='1',mac_len=8)
>>> (a,b)= cipher.encrypt_and_digest('bonjour')
>>> a.encode('hex')
'2b59499b904ed4'
>>> b.encode('hex')
'ab0656a30b8d846d'
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='0',mac_len=8)
>>> (a,b)= cipher.encrypt_and_digest('bonjour')
>>> a.encode('hex')
'0f11e2308749e1'
>>> b.encode('hex')
'a2a1a8b781417447'
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='0',mac_len=8)
>>> cipher.decrypt_and_verify(a,b)
'bonjour'
>>>
>>> cipher =
AES.new(key='totototototototo',mode=AES.MODE_GCM,nonce='0',mac_len=8)
>>> cipher.decrypt_and_verify(a,'a2a1a8b781417448'.decode('hex'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py", line
1035, in decrypt_and_verify
self.verify(mac_tag)
File "/usr/local/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py", line
969, in verify
raise ValueError("MAC check failed")
ValueError: MAC check failed
⇒On vérifie que la version de PyCrypto est la bonne version ;
⇒On utilise AES en mode AES_GCM avec un nonce de 0 et une taille d’étiquette de 8 octets ;
⇒l’opération encrypt_and_digest permet de réaliser un chiffrement et une authentification : elle
⇒a qui est le chiffrement de la chaîne "bonjour" ;
⇒b qui est l’étiquette d’authentification ;
⇒On veut vérifier les données reçues : on recrée un objet AES muni des mêmes informations que précéretourne ici le tuple (a,b) :
⇒On fournie à la méthode decrypt_and_verify les valeurs de a et b obtenues précédemment et
demment (même clé et même nonce) ;
⇒On vérifie que le traitement est reproductuble.
⇒On essaye avec une valeur différente du nonce ;
⇒On modifie l’étiquette obtenue précédemment (on passe de 'a2a1a8b781417447' à
on obtient bien la chaîne initiale avec une authentification correcte ;
'a2a1a8b781417448') et on obtient une exception : ValueError("MAC check failed").
Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
5/6
Travail à réaliser
□ Concevoir un protocole sécurisé permettant de transmettre des paquets d’au plus 32 octets et
comportant une adresse source et destination sur 5 octets chacune :
⋄ le message est chiffré et authentifié en AES-GCM-128.
□ Utilisation du Raspberry Pi et du composant nRF24L01 en mode alternat :
⋄ dérivation du code depuis l’exemple du programme « ping/pong » ;
⋄ A envoi à B la clé de session chiffrée avec la clé publique de B (ping) ;
⋄ A envoi un message chiffré à l’aide de la clé de session échangée (ping) ;
⋄ B déchiffre et affiche le message reçu (il peut confirmer la réception avec le pong).
□ Ce protocole est mis en œuvre dans un programme Python qui :
⋄ gère le PKG et manipule les différentes clés : la biclé RSA de l’utilisateur, la clé de session
⋄ crée le contenu du message chiffré et l’envoi par radio en utilisant une commande externe en
AES-128, les données d’authentification utilisées pour le GCM ;
C d’envoi de paquet :
⋆ dérivée du programme « ping/pong » de la bibliothèque de communication nRF24L01 ;
⋆ acceptant en entrée le paquet chiffré et authentifié, c-à-d les 42 octets qui le compose :
adresse source 5 octets adresse destination 5 octets message sur 32 octets
⋆ affichant à l’écran en notation hexadécimale/ASCII le contenu du paquet à envoyer :
⋄ reçoit, déchiffre et vérifie l’authentification d’un paquet en utilisant une commande externe en
C de réception d’un paquet :
⋆ dérivée du programme « ping/pong » de la bibliothèque de communication nRF24L01 ;
⋆ fournissant en sortie le paquet chiffré et authentifié, c-à-d les 42 octets qui le compose :
adresse source 5 octets adresse destination 5 octets message sur 32 octets
⋆ affichant le contenu du paquet en hexa/ASCII.
□ Vous réfléchirez et construirez votre protocole de manière à :
⋄ lier authentification, adresse, et clé publique de l’IBE (par exemple en vous inspirant de
⋄ partager la clé de chiffrement AES-128 entre expéditeur et destinataire en sachant que l’IBE
SUCV) ;
est présent sur les deux, inclus dans une carte à puce (dans votre programme Python vous
pourrez, bien sûr, simuler sa présence en disposant directement des éléments qu’il pourrait
vous donnez, mais en indiquant comment vous les récupérez auprès de lui) ;
⋄ proposer une fragmentation des échanges et une résistance aux pertes de paquets en utilisant
un numéro de séquence (en adaptant la taille du « tag authentication »).
□ Vous enverrez le résultat de votre travail sous forme d’une archive zip/tar.gz à [email protected]
avant le 26 février 2016.
Resp. UE : P-F. Bonnefoi, http://p-fb.net/, « TMC–Projet » version du 9 février 2016, rédigé avec ConTEXt – Don’t Panic !
6/6