nfc – OVERSIMPLE

Réaliser un lecteur de badge avec rasberry pi (Partie 2)

Introduction

La semaine dernière, nous en étions restés à la compilation de la librairie libnfc. Si vous avez besoin de vous rafraîchir la mémoire c’est par ici. Aujourd’hui nous allons voir comment lire un badge tel que les badges d’entrée d’immeuble avec un programme en C qui tournera sur raspberry Pi.

Lecture de l’uid

Tout d’abord, il est important de savoir que seul un numéro de série est lu par beaucoup de lecteurs de cartes pour le contrôle d’accès. Ceci n’est absolument pas sécurisé et il est possible d’acheter des cartes (sur le marché chinois) permettant de copier ces badges en utilisant le programme d’exemple nfc-mfsetuid disponible dans le dossier exemple. D’ailleurs, les serruriers ne font qu’une simple copie de votre badge vers un nouveau avant de le verrouiller en écriture.

Il serait tout a fait possible de réaliser un protocole sécurisé mais pour cela, il faudrait des badges équipés de capacité cryptographique et donc plus chers. Les badge d’entrée les plus fréquemment utilisés sont des badges Mifare qui ne coûtent vraiment pas grand chose : MIFARE 4K NXP blanche haute qualité Par 5000 = 0.90 € unitaire trouvé sur google.

Nous allons faire comme eux et simplement lire l’uid. Nous ne prétendrons cependant pas que ce soit sécurisé. Pour cela allons dans le dossier exemples/ et lançons le programme suivant :

sudo ./nfc-poll

Et voilà vous venez de lire l’UID de votre badge !

Code C

Nous allons maintenant repartir du programme nfc-poll afin de le personnaliser et de le réutiliser dans notre application. Toujours dans le dossier exemple :

mkdir badgeReader/utils/
cp nfc-poll.c badgeReader/badgeReader.c
cp ../utils/nfc-utils.h examples/badgeReader/utils/
cp ../utils/nfc-utils.c examples/badgeReader/utils/
cd badgeReader/
gcc badgeReader.c utils/nfc-utils.c -lnfc -o myBadgeReader.o
sudo ./myBadgeReader

Félicitation, vous venez de compiler votre première application avec libnfc. Je vous conseille de garder ce squelette de coté, il constitue une bonne base pour commencer avec le NFC.

Vérifier l’UID

Bien, pour l’instant, nous ne faisions que d’afficher l’UID en réutilisant les programmes déjà présents. nous allons maintenant le récupérer et le comparer afin de vérifier si la personne est autorisée à entrer ou non.

Copier le squelette précédemment construit et remplacer le fichier badgeReader.c par celui écrit ci dessous :

/**
 * @file badgeReader.c
 * @brief read a badge and print a message if the badge is the one attended
 */
 
#include <err.h>
#include <signal.h>
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
 
#include <nfc/nfc.h>
#include <nfc/nfc-types.h>
 
#include "utils/nfc-utils.h"
 
static nfc_device *pnd = NULL;
 
int main(int argc, const char *argv[])
{
	const unsigned char referenceUID[7] ={0x04, 0x3c,  0x76,  0x7a,  0xa6,  0x27,  0x80};
	const unsigned char referenceUIDsz = 7;	
 
	const unsigned char uiPollNr = 20;
	const unsigned char uiPeriod = 2;
 
	/* Defines the modulation types
	 * for the mifare types, only the type A is requested */
	const nfc_modulation nmModulations[1] = {
		{ .nmt = NMT_ISO14443A, .nbr = NBR_106 },
	};
 
	int i;
	const size_t szModulations = 1;
 
	nfc_target nt;
	int res = 0;
 
	nfc_context *context;
	nfc_init(&context);
 
	/* We open the pn53x */
	pnd = nfc_open(context, NULL);
 
	if (pnd == NULL) {
		ERR("%s", "Unable to open NFC device.");
		exit(EXIT_FAILURE);
	}
 
	if (nfc_initiator_init(pnd) < 0) {
		nfc_perror(pnd, "nfc_initiator_init");
		exit(EXIT_FAILURE);
	}
 
	if ((res = nfc_initiator_poll_target(pnd, nmModulations, szModulations, uiPollNr, uiPeriod, &nt))  < 0) {
		nfc_perror(pnd, "nfc_initiator_poll_target");
		nfc_close(pnd);
		nfc_exit(context);
		exit(EXIT_FAILURE);
	}
 
	if (res > 0) {
		printf("Read UID     : ");
		print_hex(nt.nti.nai.abtUid, nt.nti.nai.szUidLen);
		printf("Expected UID : ");
		print_hex(referenceUID, referenceUIDsz);
 
	} else {
		printf("No target found.\n");
	}
	nfc_close(pnd);
	nfc_exit(context);
	exit(EXIT_SUCCESS);
}

Vous pouvez maintenant comparer vos deux UID dans un programme.

Conclusion

Pourquoi ne pas ajouter un module comme celui ci à votre raspberry pi et continuer les développement vers quelques chose de plus sécurisé avec l’ajout d’un code PIN par exemple.

It’s oversimple, isn’t it?

Réaliser un lecteur de badge avec rasberry pi (Partie 1)

Introduction

Un article en deux parties.Une première cette semaine pour vous expliquer comment installer la librairie sur votre raspberry pi. Le prochain article décrira comment réaliser un programme en C pour lire un badge de type badge d’entrée des immeubles.

La librairie libnfc

La librairie libnfc est une librairie dédiée à la communication en NFC. Cette librairie est publieé sous licence LGPL (libre de droit pour les applications libres ou commerciales).

Celle-ci fonctionne avec un hardware spécifique, on peut trouver la liste sur le wiki de libnfc.

Pour ma part, j’ai un dongle usb équipé d’un PN533 (fabriqué par NXP). La photo est ci dessous :

Télécharger la librairie

Les liens du wiki officiel sont brisés mais une petite recherche google nous permet de retrouver la release. Pour les projets sur le Pi, privilégiez les versions packagées aux versions développeurs.

wget https://libnfc.googlecode.com/files/libnfc-1.7.0-rc3.tar.gz
tar -xvzf libnfc-1.7.0-rc3.tar.gz 
cd libnfc-1.7.0-rc3/

Configuration

Si vous souhaitez configurer la librairie pour un pn532 en UART comme ceux de chez Adafruit il va falloir commencer par libérer l’UART du pi comme indiqué dans cette article :

Puis une fois l’UART libéré, il va falloir copier le fichier de configuration comme suit :

sudo mkdir -p /etc/nfc/devices.d
sudo cp contrib/libnfc/pn532_uart_on_rpi.conf.sample /etc/nfc/devices.d/pn532_uart_on_rpi.conf

Editez ensuite le fichier suivant :

sudo nano /etc/nfc/devices.d/pn532_uart_on_rpi.conf

Et modifiez la ligne suivante à la fin du fichier

allow_intrusive_scan = true

Compilation

Enfin nous pouvons maintenant compiler les sources :

./configure --with-drivers=pn532_uart --sysconfdir=/etc --prefix=/usr
autoreconf -vis
make clean
sudo make install

Et pour tester :

cd utils/
sudo ./nfc-scan-devices

Et vous devriez voir apparaître quelque chose comme ça :

1 NFC device(s) found:
- NXP / PN533:
    pn53x_usb:002:003

Conclusion

En attendant l’article de la semaine prochaine (il est déjà écrit, il ne reste qu’à le mettre en page), vous pouvez parcourir le dossier exemple/. Vous y trouverez de quoi vous amusez un peu avec diverses badges du quotidien.

Attaque sur carte sans contact

Un petit retour sur le workshop de la Nuit du Hack.

La démonstration principale de ce workshop était une attaque sur les cartes sans contact. Celles-ci proposent de payer en sans contact à une distance d’une dizaine de centimètre du lecteur. Ce paiement ne nécessite pas de saisir son code PIN. Il est cependant limité à des transactions d’un montant maximal de 20€ et à 4 transactions consécutives. Après il faut passer en mode contact pour réaliser une transaction.

Description de l’attaque

L’idée est de réaliser un proxy permettant de faire une transaction à distance.

Le téléphone est un téléphone NFC qui permet de réaliser des transactions en sans contact. Celui-ci est relié par un réseau, par exemple un réseau internet, à un lecteur de carte sans contact. Ce lecteur dans le schéma est représenté à droite à coté du personnage en costume. Il est relié à un ordinateur afin de pouvoir être accessible depuis un réseau.

Nous aurions aussi pu utiliser un autre téléphone NFC à la place du couple PC – lecteur sans contact. Cependant je n’avais à ma disposition qu’un seul téléphone NFC.

L’attaque consiste à réaliser un proxy passif afin de réaliser un paiement à l’aide d’une carte qui ne se trouve pas à proximité du lecteur. Puisque la technologie est sans contact, cela peut être réalisé à l’insu de la cible.

Réalisation

Afin de réaliser cette attaque, un téléphone Nexus S a été utilisé. Ce téléphone possède une puce NFC et permet l’installation de l’application simply tap avec une cyanogen mod 9.1. Cette application permet d’avoir accès à l’antenne NFC du téléphone depuis une application android. Le but premier est de réaliser des services de paiement en cloud.

Dans notre cas, au lieu d’interroger un cloud, nous interrogeons un lecteur distant afin de dialoguer directement avec une carte sans contact.

Démonstration :

Attaque par proxy par oversimple

Comment s’en protéger

Pour s’en protéger, c’est assez simple il suffit de mettre sa carte dans un étui en fer. Il existe des portes feuilles blindés qui font très bien l’affaire.

Bibliographie

SimplyTapp NFC Payment System Debuts with CyanogenMod 9.1
emulating pki smart card with cm9.1
NFC Proxy

Nuit du Hack 2k13

Un petit bilan de la nuit du hack.

Un petit retour sur la Nuit du hack qui vient de se passer. Cette année les confs étaient essentielement en anglais. On peut y voir une volontée de s’ouvrir de plus en plus vers l’étranger.

Le thème du SE est revenu assez fréquement. On a eu comme toujours le droit à notre lot de surprises. Nous avons une petite préference pour les techniques roumaines de fraudes bancaires sur internet.

L’idée est simple, convertir des euro en leu roumain (l’argent roumain) et utiliser les arrondis du troisième digit pour se retouver avec un arrondi supérieur en notre faveur. Ce qui est amusant c’est de voir comment avec ingéniosité il a automatisé les vérifications du code secret qui valide les transactions. Ses automates valent le détour.

Sinon, Julien a présenté un workshop sur le NFC. Le workshop s’est bien déroulé et nous avons pu établir quelques contacts. C’est assez suprenant de voir que les gens s’intéressent autant à la technologie.

Après tout ça on est allé faire un petit tour dans les jardins du parcs avant que les gardes nous demandent de rentrer dans nos hotels. Pour le coup, on ne comprend vraiment pas pourquoi.

On postera d’autre trucs plus tard sur le workshop et les challenges du wargames mais pour l’instant il est l’heure d’aller se coucher.

Hacking the NFC credit cards

On a pas mal entendu parler du soit disant fail de la technologie utilisée par les cartes sans contact.

Tout d’abord, revenons sur l’article publié par Korben. Quel ne fut pas notre étonnement de voir sur ce site, que nous suivons régulièrement (et passionnément), cet article. Entrons dans les détails d’une transaction, afin de comprendre pourquoi, il est impossible de dupliquer une carte bancaire aujourd’hui.

Les clés utilisées pour les transactions bancaires verrouillées avec des clés de chiffrement privé qui ne sont possédées que par la banque et la carte. Ces clés sont inaccessibles (à part pour la carte et la banque bien sur).

La question se pose quand à la possibilité d’obtenir des informations non confidentiels mais nuisibles à la vie privée des utilisateurs. Les informations disponibles ne sont rien d’autre que celles présentes en clair sur la carte. Donc plutôt que de pouvoir récupérer ces informations via un système complexe d’antenne NFC, pourquoi ne pas tout simplement se munir de bons yeux et lire par dessus l’épaule des utilisateurs. (Ou encore de bonnes oreilles et d’écouter le boulanger dire bonjour monsieur Dupont).

L’article de Renaud

Comme le souligne judicieusement les slides de la présentation, le protocole contactless est calqué tant au niveau protocolaire que du point de vue de l’application sur les principes « contact ». En fait, pour aller plus loin la spécification applicative qui décrit le processus de la transaction bancaire est totalement indépendant du protocole de communication utilisée. La norme ISO 7816 citée dans les slides est bien une référence, mais pour le protocole de communication contact. Pour la partie contact, inutile de chercher des informations dans cette norme, allez plutôt voir l’ISO 14443.

Après seulement 3 slides, je commence déjà à douter du sérieux et des connaissances de ce Renaud.

Un soucis sur les protocoles

Sans entrer dans les détails, l’attaque porte sur la possibilité de dupliquer les données publiques de la carte. Les plus malins d’entre vous aurons remarqué qu’il s’agit des données publiques. En gros, celles qui ne permettent pas de réaliser de fausse cartes. Les clés cryptographiques sont quant à elles bien gardées au chaud. De plus, ceci n’est vrai que si la personne ne possède pas plusieurs cartes de ce type. En effet, si plusieurs cartes sans contact sont présentes, il y a une collision et le lecteur est incapable d’identifier quels octets proviennent de quelles cartes. Pour faire de la lecture en masse dans une foule, çela pose déjà un assez gros problème.

Ensuite, les données présentes sur la piste magnétique sont aussi présentes dans l’application sans contact. Cette affirmation erronée vient d’une mauvaise compréhension des spécifications d’implémentations. En effet, les cartes sans contact proposent une version de paiement utilisant un mécanisme très similaire à celui des bandes magnétiques pour les petits paiements. Le mécanisme utilisé les CVC Track 2 et 3 qui sont des données équivalentes aux données que l’on trouve sur une piste magnétique. Cependant les données présentes dans la carte à puces ne sont pas les mêmes que sur la piste magnétique et ne sont pas valides pour des paiements par piste magnétique.

Source : Hacking the NFC credit cards for fun and debit 😉
Source : EMV Book 2 – Security and Key Management
Source : EMV Book 3 – Application Specification
Source : Korben

It’s over simple, isn’t it?