Mois : juillet 2012

Synchronisation sur un protocole bas niveau

Nous sommes en mesure d’espionner les premières transactions. Il ne nous reste plus qu’à configurer l’affichage sur la dalle tactile. Cet article va présenter la façon dont nous avons choisi de nous synchroniser avec le signal que nous espionnons. Cette méthode peut être extrapolée à d’autres protocoles de communication.

Synchronisation entre l’espion, le terminal et la carte

Les communications avec cartes à contact suivent la norme iso7816. Les communications sont réalisées en passant, sur la ligne, un état haut ou un état bas. Ce niveau logique doit être appliqué pendant une certaine durée; la durée de transmission d’un caractère. Afin de faire simple, cette durée dépend de la fréquence d’horloge appliquée à la carte par le terminal.

On peut le définir tel que :

Tc = a*f 
où :
f est la fréquence
Tc est la durée d'un caractère
a est un facteur de proportionnalité

Le temps que dure un caractère peut changer durant la transmission mais il sera toujours fonction de la fréquence. Pour le modifier, la carte demande à ce que se soit la valeur de a qui évolue.

Une explication plus détaillée (et surtout plus juste) est faite dans la norme iso 7816 ou bien dans l’EMV book 1 téléchargeable sur le site d’EMVco : http://www.emvco.com/specifications.aspx?id=223

Trame observée

La première action consistait à visualiser le signal obtenu. Pour ce faire,  j’ai décortiqué la norme et pris un oscilloscope. Dans le cas étudié, la première chose transmise est un octet décrivant le codage des caractères (Big endian / Little endian). Il est transmis par la carte et ressemble à ceci :

On remarque alors qu’aux temps t1 et t2, nous avons, bien que le caractère soit différent, un front descendant. Ceci correspond, d’après la norme, à la transmission de trois bits. Nous allons donc nous synchroniser sur ces deux fronts descendants lancer un compteur de temps et diviser le résultat par trois afin d’obtenir la durée de transmission d’un bit.

Code

Nous codons ceci sur un micro-contrôleur pic32. Le modèle de notre PIC est le pic32mx795F512L.
Configuration de l’interruption qui doit se déclencher sur les fronts descendants:

 /* Configure the interupt on IO to answer on each falling edge*/
    ConfigINT2(EXT_INT_ENABLE | FALLING_EDGE_INT | EXT_INT_PRI_1);

Implémentation de l’interruption pour lancer le timer 1 lors du premier front descendant puis le couper lors du second.

unsigned int state = 0;
unsigned int bitDuration = 0;
 
/* INT2 ISR */
/* Interruption externe 2 */
void __ISR(_EXTERNAL_2_VECTOR, IPL1) _Int2Handler(void) {
 
    /* State = 0 il s'agit du premier front descendant */
    if(0 == state)
    {
        /* Configure le Timer1*/
        mT1ClearIntFlag();
        /*Lance le timer 1 */
        OpenTimer1(T1_ON | T1_SOURCE_INT | T1_PS_1_1, 64000);
        state = 1;
    }
    else if(1 == state)
    {
          ConfigIntTimer1(T1_INT_OFF);
          bitDuration = ReadTimer1()/3;
    }
    /*Efface le flag d'interruption*/
    mINT2ClearIntFlag();
}

bitDuration contient alors le nombre de coups de clock que l’on doit compter pour obtenir le temps de transmission d’un bit.

It’s OverSimple, isn’t it?

Et si on sauvegardait notre base de données ?

Avoir un site web c’est bien, mais en faire des sauvegardes ça peut toujours être utile. L’objectif de cet article est de vous montrer comment on sauvegarde notre base de données. Le principe de cette sauvegarde est simple. Ovh éxecute un script que l’on aura stocké sur notre espace personnel. Ce script sauvegardera notre base de données et on obtiendra un fichier SQL contenant notre BDD. Ensuite, un autre script, qui se trouve sur mon serveur personnel, se connectera afin d’aller chercher cette sauvegarde. Vous allez me dire, pourquoi c’est mon serveur qui se connecte au serveur Oversimple ? Tout simplement car je considère que mon serveur est « fiable » contrairement à un serveur mutualisé d’OVH.

Script PHP sur serveur OVH.

<?php
#php doit être supérieur à 5.1

$user="login";
$password="mot de passe";
$nom_de_la_base="baseName";
$serveur_sql="le serveur";
 
#Recupération de la date du jour : JJ-MM-AAAA 
$dateArchive =  date("d-m-Y");
 
#Sauvegarde de la base -> sortie vers un fichier sql -> overSimple-DD-MM-YYYY.sql
system("mysqldump --host=$serveur_sql --user=$user --password=$password $nom_de_la_base > overSimple-$dateArchive.sql");
 
#Récupération de la date a moins 28 jours afin de viser une ancienne archive
$newDate = strtotime('-28 day', strtotime ($dateArchive) );
$newDate = date('d-m-Y', $newDate);
 
#Verification si l'archive existe, on la supprime afin de ne pas en avoir de trop
if(file_exists("overSimple-$newDate.sql")){
	unlink("overSimple-$newDate.sql");
}
 
?>

Script Shell sur mon serveur personnel

#!/bin/sh
 
HOST='le ftp'
PORT='21'
USER='le login'
PASSWORD='un mot de passe ;)'
 
DATE=`date +%d-%m-%Y`
NAME_FILE=overSimple-$DATE.sql
 
#On va dans le repertoire de sauvegarde
cd `dirname $0`
ftp -n $HOST $PORT <<END
quote USER $USER
quote PASS $PASSWORD
cd sauvegarde/
get $NAME_FILE
quit
END
 
#On vérifie si on a télècharger le fichier.
if [ ! -f $NAME_FILE ]
then
    echo "Le fichier n'existe pas !, on le reprogramme pour dans 2 heures"
    echo sh $0 | at now + 2 hours
fi
 
exit

On plannifie l’execute sur OVH

Tous les lundis à 1h du matin. (Hébergement -> Planificateur de tâches)

On planifie sur le serveur

Pour cela rien de bien compliqué, une petite tache cron chaque lundi à 2h du matin (on a de la marge) :

$ crontab -e
00 02 * * 1 /home/overSimple/sauvegarde/sauvegarde.sh
 
On quitte (:wq) et on obtient :
crontab: installing new crontab

Et voilà, on obtient une petite sauvegarde hebdomadaire !

Espionner une transaction avec carte à puce

La suite de l’article d’introduction sur la réalisation d’un espion pour carte à puce.
Afin de rendre les choses plus explicites on commence par un petit schéma :

Diagramme en boite de l'espion
Diagramme de l’espion de carte à puce

Le micro-contrôleur va lire les niveaux logiques qui circulent sur les entrées/sorties de la carte à puce. Pour cela il est nécessaire d’utiliser une rallonge. La construction de cette rallonge est décrite dans l’article précèdent :

Plus tard, une interface de lecture, pour les humains, sera développée avec un écran LCD. Au cous du développement, nous aurons besoin de réaliser des transactions. Cette article va traiter de la mise en place de l’environnement de test et de la lecture des données d’une carte bancaire.
Notez que nous utilisons une carte bancaire mais que ceci aurait pu marcher avec n’importe quelle autre carte à puce.

Lecteur de carte à puce

Afin de dialoguer avec la carte à puce, nous utiliserons un lecteur de carte à puce de type PC/SC. Ces lecteurs sont des lecteurs pour PC qui se connectent en USB. Il existe des librairies pour faciliter l’utilisation de ces lecteurs en Java. J’ai acheté le mien sur le site de Monéo : Boutique Moneo

une fois branché, il est nécessaire d’installer les drivers du lecteur. Pour ma Debian cela donne ça :

$:sudo apt-get install libpcsclite1
$:sudo apt-get install libacsccid1
$:sudo apt-get install pcsc-tools

Pour vérifier que l’installation s’est bien déroulée, on insère une carte dans notre lecteur et on le lance dans un terminal :

$pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR 38U-CCID 00 00
 
Mon Jun 11 20:03:00 2012
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted, 
  ATR: 3F 65 25 08 66 04 6C 90 00
 
ATR: 3F 65 25 08 66 04 6C 90 00
+ TS = 3F --&gt; Inverse Convention
+ T0 = 65, Y(1): 0110, K: 5 (historical bytes)
  TB(1) = 25 --&gt; Programming Param P: 5 Volts, I: 1 milliamperes
  TC(1) = 08 --&gt; Extra guard time: 8
+ Historical bytes: 66 04 6C 90 00
  Category indicator byte: 66 (proprietary format)
 
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3F 65 25 08 66 04 6C 90 00
3F 65 25 .. .. 04 6C 90 .0
	Carte Bancaire (Frenc

Si vous recevez une réponse du type, alors le driver pcsc est correctement installé.

Analyse de la réponse

L’ATR (Answer to reset) provient de la carte et nous indique quel protocole doit être utilisé aussi bien en terme de durée d’un caractère que de signification d’un niveau logique. Nous y reviendrons plus en détails lorsqu’il s’agira de programmer notre espion puisqu’il devra se caler sur le rythme de la transaction.

Dans le prochain article nous parlerons de l’échantillonnage à proprement parlé et nous montrerons comment se synchroniser avec les données de la carte.
Si vous souhaitez reproduire les échanges de l’article http://oversimple.fr/que-trouve-t-on-dans-une-carte-bancaire/ vous pouvez utiliser le programme gscriptor présent dans le paquetage pcsc-tool que vous venez de télécharger.

It’s oversimple, isn’t it?

Installation de GITOLITE sous OpenBSD

Gitolite est un projet Open Source permettant de gérer des droits sur les dépôts Git en utilisant le principe des ACL.

Gitolite utilise des utilisateurs virtuels qui sont basés sur un unique utilisateur système. Ces utilisateurs virtuels ne possèdent pas d’accès au shell de la machine. Un git shell leur permet d’effectuer les différentes commandes.

 Pourquoi ai je installé GITOLITE ?

Tout simplement pour les différents projets d’OverSimple.  En effet, avant d’ouvrir ce site, Julien et moi avons développer un Hotspot wifi (peut être un aperçu bientôt). Nous l’avions fait sans gestionnaire de sources,  ce qui nous a posé quelques problèmes de cohésion. Après cette expérience, nous avons décidé de mettre en place un Git. La question qui s’est alors posée concernait l’emplacement de celui-ci. Sur mon serveur ? Sur un serveur commun à nous deux ? Actuellement, nous ne possédons aucun serveur en commun. J’ai donc installé Git sur ma machine personnelle. Cependant, comment faire pour que l’on puisse travailler ensemble sans que nos projets soient dans « la nature ». La meilleure solution est d’utiliser le SSH mais comme Julien ne possède pas d’accès sur ma machine, il y avait toujours un problème… Le problème fut résolu par la mise en place de GITOLITE. Grâce a GITOLITE, je peux donner à n’importe quelle personne un accès sur le projet voulu.

Installation de GITOLITE

Dans l’article concernant l’installation de git, j’ai pu mettre en place un utilisateur « Git ». Cette utilisateur trouve tout son intérêt dans l’utilisation de GITOLITE.  Celui-ci n’a pas besoin de mot de passe car à chaque fois que l’on ajoutera un utilisateur virtuel celui devra fournir une clé publique. Cette clé publique sera ajoutée dans les authorization keys de l’utilisateur Git. Regardons le contenu de mon fichier (authorization keys) :

# gitolite start
command="/home/git/gitolite/src/gitolite-shell pierre",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC70+f4qTYTjAAwG5jjn3emRdbX2S/OccZdYg2QHGc+OL5uW+mitSvwh0wnKJYc3QzzgQ0E/GGpJkTGpzcKaFrz21lPPbjXvUb5Qa8KP11cUCcN5SREKuQem1EMCnUQGrDS94MZ1eFyma0kWGpjWXNCfaRuBcpPfh9WJ1TzTrb0jokGKFloAlzvd0Z5GGzWAWLrTlK7wIVY3Zsvde+kxJJDZkDFm3X/maOdG3Kb/EoTAH1TtG3OkDsoMu/FUogxix6eCMo5g/xREzQxXPyXHxmjY5dCfNVvg7sXx4Ss4jBz9/8vOpbPdEHykjtHBq9L38hbcfYiss4Ab4E0IC2dP+29 pierre@portable
# gitolite end

Cette clé publique correspond à l’utilisateur Pierre.

Pour cela j’ai du générer une paire de clés pour mon utilisateur Pierre. Voici la procédure :

cd ~/.ssh
ssh-keygen -t rsa -f id_rsa_git
cd -
scp id_rsa_git.pub monuser@leServeur:/home/monuser

On se connecte sur notre serveur :

cp id_rsa_git.pub /home/git/pierre.pub
exit

Attention
Lors de mes recherches sur internet pour installer git & gitolite, j’ai pu m’apercevoir qu’il existe deux erreurs récurrentes sur plusieurs sites, la deuxième dépendant de la première.

Cette première erreur consiste à générer une paire de clés pour l’utilisateur Git. En plus de générer une paire de clé qui sera très peu utilisée celle-ci sera mal gardée, c’est pour cela que c’est déconseillé par la communauté Gitolite.

La deuxième erreur est d’ajouter la clé id_rsa_git.pub dans le fichier ~.ssh/authorized_keys:
cat id_rsa_git.pub >> /home/git/.ssh/authorized_keys

Lorsque nous passons à l’installation, nous avons une alerte : WARNING: keydir/git.pub duplicates a non-gitolite key, sshd will ignore it

Si on laisse cela dans l’état, nous n’utilisons pas le shell de Git mais notre shell par défaut (dans mon cas ksh pour mon serveur).

Cependant, si vous désirez que votre utilisateur accède au shell ksh, il est préférable de générer une autre paire de clés.

Installation de GITOLITE

On se connecte sur notre utilisateur git :

# su - git

Puis on récupère GITOLITE :

git clone git://github.com/sitaramc/gitolite

On récupère le chemin en entier :

$ gitolite/install
use the following full path for gitolite:
        /home/git/gitolite/src/gitolite

Puis on effectue l’installation (vous remarquerez que j’ai mis ma clé publique)

$ /home/git/gitolite/src/gitolite setup -pk /home/git/pierre.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/

Configuration de notre client

La configuration de GITOLITE est simple, celui-ci est gérée de la même manière qu’un dépot Git.

Configurons, maintenant, notre poste client afin que cela soit plus simple:

Éditons notre fichier de configuration SSH (vim ~/.ssh/config)

Host gitolite
	User git
	Hostname IP_DE_MON_SERVEUR
	port 22
	identityfile ~/.ssh/pierre

Si la configuration ci-dessous n’est pas effectuée pour se connecter au serveur, il faudrait faire :

 git clone ssh://git@monServeur/gitolite-admin.git/

Sinon vous avez effectué la configuration du SSH, et vous pouvez utilisé soit la première ou deuxième ligne :

git clone ssh://gitolite/gitolite-admin.git/
git clone gitolite:gitolite-admin.git

De vous à moi, je préfère largement la deuxième qui est beaucoup plus simple.

Configuration de notre GITOLITE

On regarde les fichiers récuperés sur notre poste :

ls -R gitolite-admin/
gitolite-admin/:
conf  keydir
 
gitolite-admin/conf:
gitolite.conf
 
gitolite-admin/keydir:
git.pub

On peut voir le fichier gitolite.conf et le repertoire keydir.

Le fichier gitolite.conf permet la configuration des utilisateurs/groupes et les dépôts.
Le répertoire keydir contient les clés publiques des utilisateurs sous la forme nom.pub

Dans le fichier de configuration, on peut avoir plusieurs ACL pour chaque répertoire:

  • RW+ : Droits de lecture, d’écriture et de suppression d’objets particuliers tels que Branches et Tags.
  • RW : Droits de lecture et d’écriture (push)
  • R : Droit de lecture (pull,clone,fetch)
  • – : Refuser l’access (par exemple, on ajoute un groupe mais on veut refuser un utilisateur)

Pour chaque répertoire,  on peut spécifier des utilisateurs, des groupes ou bien un accès public.

Ajout d’un utilisateur

Il suffit de copier la clé publique dans le répertoire keydir récupéré en local. Prenons l’exemple de Julien :

Julien me donne sa clé publique.

cp julien.pub keydir/

On ajoute la clé dans le répertoire :

git add julien.pub
git commit -m "Ajout de l'utilisateur Julien"

Nous venons de soumettre le projet dans le répertoire local. Afin de le rendre disponible sur le serveur de référence, il faut donc effectuer un push:

git push

Création d’un répertoire oversimple :

Il faut ajouter dans conf/gitolite.conf :

repo oversimple
	RW+	= pierre julien

Création de plusieurs répertoires pour les mêmes personnes, rien de plus simple :

repo oversimple oversimple1 oversimple2
	RW+ = pierre julien

Une fois les modifications apportées, les commandes sont toujours pareilles :

$ git add conf/gitolite.conf
$ git commit -m "Ajout du répertoire oversimple"
$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 398 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Initialized empty Git repository in /home/git/repositories/oversimple.git/
To ssh://gitolite/gitolite-admin.git
   8039b66..f2b18d1  master -&gt; master

On peut remarquer la création de notre répertoire oversimple.git.

Création de groupe :

Julien et moi formons un groupe qui est oversimple. Pour les projets que l’on peut avoir en cours, d’autres personnes peuvent se greffer, par exemple, Éléonore.
Ajout dans la configuration :

@oversimple = pierre julien
OU Exactement pareil :
@oversimple = pierre
@oversimple = julien
 
repo oversimple oversimple1 oversimple2
	RW+ = @oversimple
 
repo projet1
	RW+ = @oversimple
	RW = eleonore

Bien sur une clé publique sera ajoutée pour Éléonore

Une fois terminée, toujours la même musique… git add, commit & push.

Pour terminer, testons un peu les différents droits. Mettons nous dans le cas d’ Éléonore, celle-ci a accès uniquement au répertoire projet1.

$ git clone leo:projet1
Cloning into 'projet1'...
warning: You appear to have cloned an empty repository.

Cela fonctionne parfaitement. Cependant, elle aimerait avoir accès au dossier oversimple.

$ git clone leo:oversimple
Cloning into 'oversimple'...
FATAL: R any oversimple eleonore DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly

On peut voir qu’elle n’y a pas accès, car elle n’est pas présente dans la configuration.

Nous avons un Git & GITOLITE opérationnel !

It’s over simple, isn’t it?

Que trouve-t-on dans une carte bancaire?

Que peut on lire sur une carte bancaire?
En réalité, pas grand chose, en tout cas pas grand chose de clair. Nous allons retrouver les informations tel que le PAN présent sur la devanture,  votre nom ainsi que la date d’expiration. Concrètement, voici un log commenté d’une transaction avec carte bancaire. Le log a été obtenu en réalisant une transaction avec un lecteur PCSC et en utilisant l’outil :.

Je déconseille fortement d’utiliser votre carte bancaire pour faire ce test. Tout d’abord, nous ne savons pas si les données sont stockées avec cet outil. De plus ceci est totalement illégal. Avant d’utiliser ceci, nous avons supprimé les données sensibles de la carte.

On commence par sélectionner l’application bancaire présente sur la carte à notre disposition

00 A4 04 00 07 A0000000041010

Et la réponse commentée :

6F File Control Information (FCI) Template
 	84 Dedicated File (DF) Name
 	 	A0000000041010
 	A5 File Control Information (FCI) Proprietary Template
 	 	50 Application Label
 	 	 	O V E R S I M A P P
 	 	9F12 Application Preferred Name
 	 	 	O V E R S I M A P P
 	 	87 Application Priority Indicator
 	 	 	02
 	 	5F2D Language Preference
 	 	 	f r e n
 	 	9F11 Issuer Code Table Index
 	 	 	01
 	 	BF0C File Control Information (FCI) Issuer Discretionary Data
 	 	 	DF60 Unknown tag
 	 	 	 	0B28
 	 	 	9F4D Log Entry
 	 	 	 	0B28
90 00 : Successful

On demande ensuite le Get Processing Option. Cette commande initialise la transaction bancaire.
C’est à ce moment que les compteurs de transactions de la cartes sont incrémentés.

Terminal : 80 A8 00 00 02 8300

La carte répond

77 Response Message Template Format 2
 	82 Application Interchange Profile (AIP)
 	 	3800
 	94 Application File Locator (AFL)
 	 	08010201 10010300 18010201
90 00 : Successful

L’AIP décrit les paramètres de sécurité de la carte. Il sont décrit dans l’EMV Book 3.
L’AFL liste l’ensemble des enregistrement que l’on a le droit de lire dans la carte.

Lecture des records :

Terminal : 00 B2 01 0C 17

70 EMV Proprietary Template
 	57 Track 2 Equivalent Data
 	 	1122334455667788D15031111111111111111F
90 00 : Successful

Le track 2 equivalent data est une copie des données de la piste magnétique.
On a ici le PAN : 1122334455667788 et la date d’expiration 1503 (mars 2015).

Terminal : 00 B2 02 0C 17

70 EMV Proprietary Template
 	5F20 Cardholder Name
 	 	O V E R S I M P L E . F R
 	9F1F Track 1 Discretionary Data
 	 	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
90 00 : Successful

Terminal : 00 B2 01 14 96

On retrouve à l’intérieur la clé publique de la banque signée par l’autorité de certification.
Dans le cas de notre carte, il s’agit de Mastercard.

Terminal : 00 B2 02 14 56

70 EMV Proprietary Template
 	8F Certification Authority Public Key Index
 	 	01
 	92 Issuer Public Key Remainder
 	 	94AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 	9F32 Issuer Public Key Exponent
 	 	03
 	9F47 Integrated Circuit Card (ICC) Public Key Exponent
 	 	03
 	9F48 Integrated Circuit Card (ICC) Public Key Remainder
 	 	BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 	9F49 Dynamic Data Authentication Data Object List (DDOL)
 	 	9F3704
90 00 : Successful

On retrouve là encore des clés de signatures. Cependant on remarque aussi la présence
du tag 9F49 qui désigne les donnés que requiert la carte pour générer une signature RSA.
La carte demande dans cet exemple un nombre aléatoire de 4 octets.

Terminal : 00 B2 03 14 97

Ce record contient la clé publique de la carte signée par la banque.

Terminal : 00 B2 01 1C 58

70 EMV Proprietary Template
 	5F25 Application Effective Date
 	 	130301
 	5F24 Application Expiration Date
 	 	150330
 	5A Application Primary Account Number (PAN)
 	 	1122334455667788
 	5F34 Application Primary Account Number (PAN) Sequence Number
 	 	00
 	9F07 Application Usage Control
 	 	FF00
 	8E Cardholder Verification Method (CVM) List
 	 	000000000000000042514403010302031E031F03
 	9F0D Issuer Action Code – Default
 	 	B840FD8000
 	9F0E Issuer Action Code – Denial
 	 	0010000000
 	9F0F Issuer Action Code – Online
 	 	B860FD9800
 	5F28 Issuer Country Code
 	 	0250
 	9F4A Static Data Authentication Tag List
 	 	82
90 00 : Successful

La CVM list décrit la manière dont peut être authentifiée le porteur de la carte.
(Code pin, signature etc…)
Les action codes décrivent la politique de sécurité de la carte. Ainsi, c’est en fonction
de ces codes qu’elle choisit de refuser une transaction, d’aller en ligne demander à
sa banque ou bien de l’accepter directement sans aller en ligne.
Les cartes d’étudiants vont généralement systématiques interroger la banque alors que
les cartes plus haut de gamme se valident les transactions en offline.

Terminal : 00 B2 02 1C

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Le record qui va nous permettre de terminer la transaction. Dans celui se trouve
les donnés que la carte requiert pour générer le cryptogramme qui valide la
transaction.

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Dans le premier generate application cryptograme la carte demande 43 octets de donnés. Nous
les remplierons avec des zéros. Dans la réalité on y retrouve la date, le montant, etc…

80 AE 40 00 2B 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Nous indiquons que nous souhaitons approuver la transaction directement. La carte devrait répondre
qu’elle refuse la transaction car le code pin n’a pas était validé. Ceci n’est pas forcément vrai.
En effet, la carte peut répondre qu’elle accepte la transaction. La preuve ci dessous :

77 Response Message Template Format 2
 	9F27 Cryptogram Information Data
 	 	40
 	9F36 Application Transaction Counter (ATC)
 	 	0042
 	9F26 Application Cryptogram
 	 	1122334455667788
 	9F10 Issuer Application Data
 	 	4F56455253494D504C452E46520000000000
90 00 : Successful

Le cryptogram Information Data (CID) indique 40,  ce qui signifie que la carte a approuvé la
transaction. Bien entendu ceci ne marche que parce que nous avons judicieusement choisi
de mettre un montant égal à 0;
Il est inutile de penser que la sécurité des carte bancaires
est à remettre en question. Il est toujours bien plus facile de braquer le sac à main
d’une personne âgée que de pirater des cartes bancaires.

Installation de GIT sous OpenBSD

Pour rappel, Git est un logiciel de versions décentralisées. C’est un logiciel libre créé par Linus Torvalds.

Son fonctionnement est simple :

Git indexe tous les fichiers en effectuant un SHA-1 sur chaque fichier. Si un fichier est modifié, le SHA-1 sera différent et donc Git stocke en plus la nouvelle version. De plus, si le SHA-1 est identique alors c’est que le fichier n’est pas modifié.

Installation de Git

Passons à l’installation sous OpenBSD 5.1, rien de bien compliqué :

# pkg_add -i git

Ajoutons un utilisateur, celui-ci permettra:

  • D’exécuter le daemon Git.
  • De pouvoir se connecter en SSH avec un utilisateur différent pour son système. (Évolution avec Gitolite)
  • D’ordonner ses répertoires, si on travaille sur un même système, il est intéressant qu’un utilisateur soit créé pour gérer l’ensemble des projets.
 # adduser git

Client

Avant de passer à l’utilisateur du serveur Git, nous allons configurer notre client:

Mettons de la couleur dans Git grâce aux commandes suivantes :

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto

Puis, on configure notre identifiant (pour ma part,  mon prénom) ainsi que l’adresse mail:

$ git config --global user.name Pierre
$ git config --global user.email pierre@oversimple.fr

De plus, des alias peuvent être mis en place. Par exemple pour « Git commit » on peut faire un « Git ci »:

git config --global alias.ci commit

La configuration ci-dessus est présente dans le fichier .gitconfig. Il se trouve dans notre répertoire personnel.

$ cat ~/.gitconfig
[color]
        diff = auto
        status = auto
        branch = auto
[user]
        name = Pierre
        email = pierre@oversimple.fr
[alias]
        ci = commit

Utilisation du serveur Git

Créons notre projet Git :

$ mkdir monProjet
$ cd monProjet
$ git init

Notre répertoire étant créé, il existe plusieurs méthodes disponibles pour travailler avec Git:

  • Clone en local : git clone monProjet monProjetDeTravail
  • Clone grâce au daemon git :
    1. Exécuter le daemon git (sur le serveur): /usr/local/libexec/git/git-daemon –verbose –base-path=/home/pierre/git/
    2. Récupérer le dépôt sur le poste client : git clone git://monServeur/monProjetgestion
  • Clone via SSH :git clone ssh://git@monServeur/monProjet

 

Pour ajouter un fichier :

 $ git add nomFichier

Pour ajouter le contenu d’un répertoire:

 $ git add monRepertoire/

Pour ajouter tous les nouveaux fichiers (ou les modifier):

 $ git add .

On peut aussi supprimer un fichier ou un répertoire:

$ git rm nomFichier
$ git rm -r monRepertoire/

On commit notre changement (ajout/modification/suppression) :

 $ git commit -m "Ajout du nomFichier"

Retourner au dernier commit :

 $ git reset --hard HEAD

Visualiser les logs des différents commits:

 $ git log

On envoie les modifications sur le serveur afin qu’elles soient disponibles pour les autres utilisateurs, la première fois :

 $ git push origin master

Puis après :

 $ git push

Mettre à jour son dépôt local :

 $ git pull

Il existe plein d’autres possibilités; notamment la gestion des différentes branches.

It’s over simple, isn’t it?