Informatique & Geeks
Unbrick tenda A6 router
I've been buying Tenda A6 wifi router for object/arduino connection to internet : it's very litlle, chip, wifi, ethernet and usb powering enable.
Interesting option for "internet of things".
Two versions : one has only three modes, and chinese only, the other has 5 modes and is in english.
If you have chinese one, here is the firmware to transform in english 5 modes version .A5S-to-A6_EN.jpg
Rename this file .bin
After changing to last version, 20.ENG , Tenda A6 has brick.
Still don't know why....
I had to find a solution to unbrick it.
After opening the box, you can see an unpopulated USB connector.
This was not useful (i tried soldering usb connector, but this didn't give acess to console mode).
I had to search for Tx / RX /GND.
I am using FTDI connector you can see here : FTDI 2303 for ATMEGA sketch upload : some problems resolved.
I have been wiring + 5V and GND to USB connector, and founded RX and TX on PCB.
Here is power connection : GND and 5V :
Here is the RX pad soldered , TX pad is just below
After this i used FTDI to connect to my computer.
Using putty to open terminal/console ; baud rate is 56700.
Now you are logged in , Tenda A6 is speaking to you ;-)
After that you have to run TFTP server on your computer, connect via Ethernet, and configure option for uploading firmware.
Anything is well explained here :
Next setup your computer ip address to 192.168.0.2 and install a tftp server (I used the one provided by TENDA) you can find it here ->http://www.tenda.cn/uploadfile/downloads/uploadfile/200911/TENDA%20TFTP.zip
Regarding the tftp server:
Create a folder called "tftp" to your c:\ partition and extract into the "tftp" folder the content of the archive "TENDA 20TFTP.zip" (TENDA TFTP.exe file), than move into the "tftp" folder the firmware that you want to upload (let`s call it "new_firmware.bin") and run "TENDA TFTP.exe", click the "browse" button and select "c:\tftp" and hit "ok". The tftp server it runs on port 69.
Now download "putty" from here -> http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Run "putty.exe", setup -> on "Connection type" select "Serial", on "Host name" enter "COM3" (note I have COM3 but it might be any number you can check it in Device Manager) and click OPEN.
Now, using a UTP Cable connect your computer to the switch port 1-4 of the router, next connect the serial cable (level converter...etc) to the router and the power cable to the router (power led of the router will turn green).
Back to putty window:
As soon as you see in your putty window this output press 2 (key 2) you have 1 second to do that:
| Quote: | ||
|
Press 2 fast (max 1 second to do that...you need to be fast)
If you got it you will see this:
| Quote: | ||
|
Hit Y (key Y) and you will see this:
| Quote: | ||
|
Write the ip of the W311R (192.168.0.1) like this and hit enter:
| Quote: | ||
|
Next you will see:
| Quote: | ||
|
Write the ip of your computer (where the tftp server is running 192.168.0.2) like this and hit enter:
| Quote: | ||
|
Next you will see:
| Quote: | ||
|
Write the firmware name that you want to upload (and it is located under c:\tftp folder ... in our case new_firmware.bin) like this and hit enter
| Quote: | ||
|
Now, if you did all that I said and not other things you will see this:
| Quote: | ||
|
Now your router is back on track and it can be accessed from http://192.168.0.1 with user: admin and password: admin . Don`t forget to do a "reset to default" to be sure that all settings are set to default.
Same thing for other routers : you have to find RX/TX/ground, and have a firmware/bootloader if you want.
Don't know if DDWRT is compatible, A6 hardware is interesting (16MB) wifi, ethernet...now RX / TX and baudrate are public, hope it's help.
Internet of things : Cablage et config Arduino promini/FTDI/Ethernet ENC28J60
Plutôt que de gérer mes documents du moment par des bookmarks, je publie ici des notes sur une réflexion technique en cours concernant "l'internet of things" ou internet des objets.
Le monde tel que nous l 'avons connu se métamorphose sous nos yeux, et après la connexion des ordinateurs, puis des mobiles et tablettes vient maintenant le temps de la connexion des objets.
Ce qui est ici intéressant est l'utilisation possible de l'open source et de l'open hardware pour que nous apprivoisions ces objets, et qu'ils puissent échanger des données que nous maitrisons.
Dans cette optique , j ai commencé un projet d'interface web/arduino, basé sur des composants ultra low cost : arduino, et interface ENC28J60. Je compte vérifier la faisabilité avec les versions miniaturisées pro mini.
Ceci permet d'échanger des données avec le web, donc de fabriquer des objets du quotidien qui nous renvoient ces données de façon ergonomique, agréable (plutôt qu 'en consultant une page web).
Et inversement, les capteurs peuvent remonter des données vers le web, le cloud, un serveur déporté....
Le premier projet est un truc de bord de mer : une horloge a marée qui fonctionne !
En effet celles du commerce ne sont jamais à l'heure , puisque les marées changent.
Récupération des données sur internet, formatage , puis affichage....
Récupération des données web :
Récupérer des données web, c'est faire du scraping ou "harvesting", et c'est déjà un métier en soi : les moteurs de recherche le font, et beaucoup de banques de données sont alimentées par des algorithmes de scraping.
Ici toutefois nous n'allons pas faire "lourd" donc pas de serveur pour le data mining ou le formatage des données, on va faire au plus court.
Après avoir cherché les fonctionnalités des librairies dispo avec l'ENC28J60, Ether a récemment mis a disposition une fonction permettant de prolonger une connexion TCP/IP : ether.persistTcpConnection(true) ; un lien vers un exemple d'utilisation se trouve en bas de page.
Il y a dans ce cas nécessité de réduire la page au maximum, afin de ne pas avoir trop de données en entrée, et ceci peut se faire en ligne : plusieurs moteurs de flux RSS permettent la création de flux a partir de pages web , dont feed43 et yahoo pipes.
Ils nécessitent un apprentissage, mais sont intéressants, et peuvent être combinés et utilisés de façon concomitante.
En pointant la librairie Ether vers la page du flux rss, on récupère des données bien formatées, avec éventuellement des arguments et balises ("fabriquées" dans feed43) : ci dessous flux feed43 en entrée de yahoo pipes.
Ceci a toutefois quelques inconvénients : le délai de mise a jour du flux RSS est de 6 heures pour une utilisation gratuite (feed43) , et un maillon supplémentaire dans la chaine est un risque technique supplémentaire.
J 'ai donc basculé vers l'utilisation de la lib UIPEthernet, qui gère bien mieux la pile TCP/IP et permet de gober d'un coup une grosse page web avec une carte arduino ; ne pas oublier de reconfigurer le pinout (CS sur pin 10 au lieu de 8).
Exemple de code ci dessous, j ai passé le baudrate à 115200, ça va plus vite ;-)
PARSING DES DONNEES WEB :
Après avoir regardé du coté de http://playground.arduino.cc/Code/TextFinder, une librairie qui permet de parser les données, j ai décidé de reprendre les choses avec feed43 et yahoo pipes, afin de formater et baliser les données issues de la page web.
- ici la page web d origine des données :
http://maree.info/58
- ici le flux rss sortant de feed43.com :
http://feed43.com/5525033514074040.xml
- ici le flux sortant de yahoo pipes, en provenance de feed43 avec les balises permettant le parsing. (HH avant les heures, MM avant les hauteurs d'eau, CO avant les coefficients).
les fonctions regex de yahoo pipes sont très puissantes et permettent une mise en forme et l'intégration de balises au flux rss.
http://pipes.yahoo.com/pipes/pipe.info?_id=7b9d0de979f84b3491b5547de1e4ab14
Seul le dernier coefficient de marée n'a pas été tagué, car il ne m'est pas utile.
Ne reste plus qu'a récupérer le flux yahoo pipes rss avec l arduino, utiliser la méthode PHP proposée par pipes, ce qui nous donne un lien utilisable par notre lib Arduino ; code Arduino :
#include <SPI.h>
#include <UIPEthernet.h>
// Enter a MAC address for your controller below.
// Newer Ethernet shields have a MAC address printed on a sticker on the shield
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
// if you don't want to use DNS (and reduce your sketch size)
// use the numeric IP instead of the name for the server:
//IPAddress server(74,125,232,128); // numeric IP for Google (no DNS)
char server[] = "pipes.yahoo.com"; // name address for Google (using DNS)
// Set the static IP address to use if the DHCP fails to assign
IPAddress ip(192,168,0,177);
// Initialize the Ethernet client library
// with the IP address and port of the server
// that you want to connect to (port 80 is default for HTTP):
EthernetClient client;
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for Leonardo only
}
// start the Ethernet connection:
if (Ethernet.begin(mac) == 0) {
Serial.println("Failed to configure Ethernet using DHCP");
// no point in carrying on, so do nothing forevermore:
// try to congifure using IP address instead of DHCP:
Ethernet.begin(mac, ip);
}
// give the Ethernet shield a second to initialize:
delay(1000);
Serial.println("connecting...");
// if you get a connection, report back via serial:
if (client.connect(server, 80)) {
Serial.println("connected");
// Make a HTTP request:
client.println("GET /pipes/pipe.run?_id=7b9d0de979f84b3491b5547de1e4ab14&_render=php HTTP/1.1");
client.println("Host: pipes.yahoo.com");
client.println("Connection: close");
client.println();
}
else {
// kf you didn't get a connection to the server:
Serial.println("connection failed");
}
}
void loop()
{
// if there are incoming bytes available
// from the server, read them and print them:
if (client.available()) {
char c = client.read();
Serial.print(c);
}
// if the server's disconnected, stop the client:
if (!client.connected()) {
Serial.println();
Serial.println("disconnecting.");
client.stop();
// do nothing forevermore:
while(true);
}
}
Ce qui nous envoie sur la console série de l'arduino :
connecting...
connected
HTTP/1.1 200 OK
Date: Sat, 10 May 2014 15:26:28 GMT
P3P: policyref="http://info.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV"
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=900
Content-Type: text/php; charset=utf-8
Age: 0
Connection: close
Via: http/1.1 r16.ycpi.ams.yahoo.net (ApacheTrafficServer/4.0.2 [cMsSfW])
Server: ATS
a:2:{s:5:"count";i:1;s:5:"value";a:6:{s:5:"title";s:7:"marées";s:11:"description";s:12:"Pipes Output";s:4:"link";s:75:"http://pipes.yahoo.com/pipes/pipe.info?_id=7b9d0de979f84b3491b5547de1e4ab14";s:7:"pubDate";s:31:"Sat, 10 May 2014 15:26:28 +0000";s:9:"generator";s:29:"http://pipes.yahoo.com/pipes/";s:5:"items";a:1:{i:0;a:4:{s:5:"title";s:152:"Sam. 10 HH04h21 HH11h00 HH16h56 HH23h26 MM8,75m MM3,75m MM9,00m MM3,55m CO46 CO52 Dim. 11 HH05h17 HH11h54 HH17h46 MM9,30m MM3,20m MM9,55m CO57 63";s:7:"y:title";s:152:"Sam. 10 HH04h21 HH11h00 HH16h56 HH23h26 MM8,75m MM3,75m MM9,00m MM3,55m CO46 CO52 Dim. 11 HH05h17 HH11h54 HH17h46 MM9,30m MM3,20m MM9,55m CO57 63";s:7:"content";s:152:"Sam. 10 HH04h21 HH11h00 HH16h56 HH23h26 MM8,75m MM3,75m MM9,00m MM3,55m CO46 CO52 Dim. 11 HH05h17 HH11h54 HH17h46 MM9,30m MM3,20m MM9,55m CO57 63";s:11:"description";N;}}}}
disconnecting.
Voilà, les horaires de marées + coef + marnages sont formatés et balisés et a disposition dans l arduino, reste plus qu'à les parser, ce qui va être easy.
La suite bientôt....
Aide mémoire de configuration
Promini alimentée en 3v3 pour compatibilité modules RF / éthernet / RFID
Pro mini tourne sous voltée sans aucun problème ; finalement si : le port série ne suuit pas les instructions console et se cale sur un baudrate différent
FTDI reconnu en dev/tty/usbserial sous mac OS
Carte configurée en arduino pro ou pro mini (3,3V 8MHZ) w ATmega 328 dans le log Arduino
Connection FTDI : RX au TX carte et RX au TX carte.
Cablage du shield ethernet ENC28J60
La lib compatible avec ENC28J60 : Ethercard
Cablage d'apres la lib : pas de pin reset ni de int/D2
Difficultés de gestion de la pile TCP/IP > non gestion de la pile / buffer avec la lib Ether deux solutions :
fonction ether.persistTcpConnection(true) de Clark, un peu sport.
ou mieux utiliser la lib UIPethernet, qui implémente la gestion de TCP/IP pile d’Adam Dunkels et gère la persistance.
Cablage de pin : attention CS sur pin dix pour cette lib.
Gros avantage : compatible avec la lib Ethernet "stock" arduino.
http://www.lucadentella.it/en/category/enc28j60-arduino/
http://bibi21000.gallet.info/index.php/fr/domotique/82-arduino-fr/185-arduino-et-enc28j60-ethercard-ou-uipethernet.html
http://www.rogerclark.net/?p=499
http://defidataplus.net/tutoriaux/recuperer-flux-rss-arduino/
http://arts-numeriques.codedrops.net/Recuperer-une-info-dans-une-page
http://web-sniffer.net/
sraping page Web sur lib UIPEthernet : juste modifier le nom de la lib en UIPEthernet, et ça roule
Web client
This sketch connects to a website (http://www.google.com)
using an Arduino Wiznet Ethernet shield.
Circuit:
* Ethernet shield attached to pins 10, 11, 12, 13
created 18 Dec 2009
by David A. Mellis
modified 9 Apr 2012
by Tom Igoe, based on work by Adrian McEwen
*/
#include <SPI.h>
#include <Ethernet.h>
// Enter a MAC address for your controller below.
// Newer Ethernet shields have a MAC address printed on a sticker on the shield
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
// if you don't want to use DNS (and reduce your sketch size)
// use the numeric IP instead of the name for the server:
//IPAddress server(74,125,232,128); // numeric IP for Google (no DNS)
char server[] = "www.google.com"; // name address for Google (using DNS)
// Set the static IP address to use if the DHCP fails to assign
IPAddress ip(192,168,0,177);
// Initialize the Ethernet client library
// with the IP address and port of the server
// that you want to connect to (port 80 is default for HTTP):
EthernetClient client;
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for Leonardo only
}
// start the Ethernet connection:
if (Ethernet.begin(mac) == 0) {
Serial.println("Failed to configure Ethernet using DHCP");
// no point in carrying on, so do nothing forevermore:
// try to congifure using IP address instead of DHCP:
Ethernet.begin(mac, ip);
}
// give the Ethernet shield a second to initialize:
delay(1000);
Serial.println("connecting...");
// if you get a connection, report back via serial:
if (client.connect(server, 80)) {
Serial.println("connected");
// Make a HTTP request:
client.println("GET /search?q=arduino HTTP/1.1");
client.println("Host: www.google.com");
client.println("Connection: close");
client.println();
}
else {
// kf you didn't get a connection to the server:
Serial.println("connection failed");
}
}
void loop()
{
// if there are incoming bytes available
// from the server, read them and print them:
if (client.available()) {
char c = client.read();
Serial.print(c);
}
// if the server's disconnected, stop the client:
if (!client.connected()) {
Serial.println();
Serial.println("disconnecting.");
client.stop();
// do nothing forevermore:
while(true);
}
}
Arduino, Lecteur RFID CPS3 à 15 euros
En décembre 2008, la société Oberthur remportait pour un peu plus de 5 ME le marché de fourniture de la nouvelle carte vitale professionelle.
A l'époque , le NFC (near field contact), le RFID, étaient totalement "hype" : à la mode, un truc qui allait emmener notre médecine dans le 21 ème siècle.
LE RFID permet de transmettre des informations sans contact, technologie utilisée pour la cartes de métro par exemple.
Cinq années plus tard nous y sommes, j ai bien ma carte CPS3, mais le RFID payé par mes (nos) impôts ne me sert à rien.
Vu que je ne vois rien venir qui m'intéresse ( des lecteurs RFID pour la cantine des hopitaux...), j ai monté un petit lecteur RFID compatible avec la CPS3.
Son cout est de moins de 15 euros, et il est totalement modulable, puisqu'on a accès au code ; les fonctions d'écriture n'ont pas été testées (il faut éviter les intrusions dans des systêmes de traitement de données) et la CPS3 ne peut aparement pas "prendre du code" en RFID (protection bas niveau embarquée?).
La consultation de documents CPS m'a fait penser que le NXP RC522 serait un bon candidat pour causer à notre CPS3 : la fréquence de travail est le 13.56MHZ, comme d'ailleurs les Skylanders, des jouets RFID.
L'utilisation d'une carte arduino "toute faite" n'est pas top, la tension de travail étant de 5,5v et ne correspondant pas a la carte RFID : mieux vaut repartir des composants.
Le matériel nécessaire comporte un ATMEGA, une bredboard, une carte RFID mifare NXP RC522, et une interface USB que j 'ai un peu bidouillé afin d'y ajouter un reset (hacker un composant CMS, c'est aussi possible avec la datasheet du composant et c’est en fait très simple avec la bonne méthode).
Ce reset permet l'upload sans reset manuel sur l'atmega ; autre solution : bien faire vos courses, et prendre un loader usb avec un pin reset....
Le total des achats doit avoisiner les 15 euros.
Ce qui est ensuite un peu compliqué, c est que la carte RFID tourne en 3,3v, y compris sur le port I2C/SPI ; le mieux est donc de se fabriquer une arduino qui tourne en 3,3v pour ne pas se fader la conversion de voltage des signaux logiques.
Le premier montage est donc une arduino très basique sur bredboard, tournant en 5,5v, à 12MHZ, avec un quartz + 2 condensateurs de 22pf. (ou un résonateur).
Tout est très bien expliqué ici.
Une fois ce montage fonctionnel, on peut uploader un bootloader en 8MHZ, qui ne nécessitera pas de quartz (utilisation de l'horloge "interne" de l atmega) , et passer en 3,3v ; on peut ensuite enlever quartz et condos.
Ne pas oublier de changer le type de carte dans les préférences logicielles (lilypad@8MHZ) , pour pouvoir loader du code.
Il ne reste ensuite qu'à cabler la carte RFID, trouver un bout de code avec les bibliothèques qui vont bien, et le retravailler, et le tour est joué.
Je peux lire ma carte CPS , son numéro de série (dans un premier temps), et jouer starwars sur un buzzer (que j ai recupéré sur une manette WII cassée) ; vous remarquerez que c 'est le code d'identification de la CPS3 qui déclenche la musique, et pas le Skylander.
Voici donc une Oraison pour le départ de M. Jean Yves Robin de la diection de l ASIP, jouée avec ma CPS3 en mode RFID.
La carte arduino permet ensuite tous types de développements : intégrer des relais par exemple (controle d accès).
Et bien entendu, on peut utiliser des tags RFID, pour tous types de dev.
http://www.youtube.com/edit?video_id=movHeYdyh9o&video_referrer=watch
FTDI 2303 for ATMEGA sketch upload : some problems resolved
I've been using FDTI 2303 usb link for ATMEGA sketch upload.
Here is a very good HOWTO.
But some informations may be useful :
About FTDI USB PL2303 , i've been buying in HK, it's possible to add a reset pin, soldering a capacitor on pin 2 : low cost ftdi don't have reset pin for arduino/ATmega.
You have to solder a ceramic capacitor (104 / 0.1uF) on pin 2 : DTR.
I've been using superglue to stick capacitor on the 2303 chip ; after that it was easy to place capacitor leg on pin DTR and just heat with the welding iron. (i had put solder on capacitor leg before this step).
I didn't think it was possible to hack CMS component before that.
Now with this 2303 USB FTDI, it's possible to auto reset ATMEGA while uploading.
For testing FTDI 2303 installation and drivers, a very simple way is to put a jumper on TX/RX pin and to open a terminal : every information you send on rx will be forwarded to tx, and will echo in terminal, if anything goes right.
Second thing : i have been making a breduino, using his own power supply.
After testing, you have to connect GND from FTDI GND to ATMEGA GND, or sketch will not upload.
Last thing : txd pin from FTDI is connected to ATMEGA RXD pin2 thru a 10k resistor.
And RXD pin from FTDI is connected to TXD ATMEGA pin 3.
Using this configuration, sketchs now upload to atmega.
FINALLY : FTDI on my MBA, blink led sketch on pin 12, Breduino DIY with ATMEGA, and very nice power supply for breadboards. Many parts coming from Ebay Seller HK : czb6721960
Carte Vitale, la plus grande mystification de la sécurité informatique ?
Depuis de nombreuses années, la France se distingue par une innovation assez datée, la carte vitale et la carte professionnelle de santé, qui "sécurisent" les informations et transactions concernant les patients ; c'est dumoins ce qui nous a été vendu.
Un peu d'historique et début des soupçons :
IL y a trois ans, lors d'un formatage de lot avant la télétransmission des actes effectués au cours de la journée, une erreur s'est glissée dans un lot (microcoupure?) et ce lot altéré n'était donc plus en état d'être télétransmis.
La cpam locale me dit de prendre contact avec mon éditeur de logiciel, auquel j'ai donc envoyé ce lot corrompu, et qui me le répara ; une fois reçu je l'ai retélétransmis.
Et puis je réalise alors que ce lot a été lu, réparé, et remis en forme sans ma carte vitale professionelle et sans la carte vitale des patients, j'interroge mon éditeur, ses explications sont "confuses".
Armé de mon éditeur de texte, je vais donc à la recherche d'un fichier B2 à télétransmettre et l'ouvre, je découvre alors que rien (ou presque) n'est crypté - chiffré plus exactement.
Il est donc possible à cette époque de fabriquer ou réparer des factures FSE non rejetées par la sécurité sociale sans CPS, sans lecteur de carte vitale, avec un simple éditeur de texte.
Quelques années passent, nouveau cahier des charges CPS 1.40, nouvelle carte CPS (appel d'offre initial de fabrication à 3 millions d euros.....) , je me dis que le progrès est passé par là.
Et puis à la suite d'une discussion le doute m'amène à reprendre quelques investigations :
je découvre que rien (ou pas grand chose) n'a changé : les fichiers de télétransmission ne sont quasi pas chiffrés , et contiennent les informations d'identification : du médecin, mais aussi du patient (numéro de sécurité sociale et date de naissance), acte en tiers payant, bénéfice de la CMU, grossesse avec date de début, accident de travail, et codage des actes en ATM (qui semble une simple translation et non pas un chiffrement des actes).
Depuis la version 1.40 certains éléments sont chiffrés, le cahier des charges n'indique pas les quels, et je me demande finalement ce qui l'est vraiment : les codes des actes semblent simplement "translatés", et non pas chiffrés : le codage des actes CCAM indique précisément ce qui a été fait au patient (tumorectomie du sein...) mais ne figure pas en l'état, est utilisé un codage dit ATM, qui est une description précise de ce qui qui a été réalisé, mais la liste ATM des actes est "confidentielle" (disponible dans tous les organismes de sécurité sociale).
Toutes ces informations non chiffrées sont lisibles plus facilement avec un utilitaire B2viewer.exe qui permet une remise en forme, et cet utilitaire se trouve sur internet en trois click (avec les versions d'essai des logiciels médicaux).
Pour ceux qui s'intéressent à la totalité des informations transitant ainsi par internet le cahier des charges de la norme B2 est disponible ici et n'a pas évolué depuis 2007.
Pourquoi s'émouvoir de cette situation ?
Tout d'abord par ce que le ministère, l'ASIP et les industriels nous ont toujours vendu de la sécurité et du cryptage, du chiffrement et s'apercevoir qu'aucune des sécurité promise n'a été activée est tout de même déstabilisant : le lecteur CPS, les certificats de sécurité, les fonctions de cryptage, quasi rien n'est fonctionnel, et tout ce bazar ne sert qu'a mettre en forme des fichiers ASCII lisibles et modifiables avec un simple éditeur notepad. (quelques éléments sont chiffrés mais je ne sais pas à quoi ils correspondent, peut être des vérifications d'intégrité).
Ce qui nous est vendu ne correspond pas à la réalité : aucune des clefs publiques de la carte cps ne me semble utilisée (sauf peut être pour le chiffrement très discret visible dans les fichiers B2 mais en tout cas pas pour le transport des flux) et les documents contractuels précisant le niveau de chiffrement et la technologie employée n'existent pas : on nous vend du marketing, pas de la sécurité.
A l'heure de la privatisation de la sécurité sociale par les complémentaires, qu'en est t'il du secret médical lorsque le codage des actes ATM permet de connaitre par la "banqueassurance" du patient, ce qui a été fait, à quelle date, et par qui (généraliste, psychiatre, cancérologue...) ?
Et enfin dernier élément : ces informations transitent par des relais mails SMTP, et par les dorsales et backbones du net, et sont aussi enregistrés, captés et stockés, si l'on en croit les récentes révélations concernant le programme PRISM et ses équivalents nationaux.
Quitte a payer un lecteur CPS, et tout le pseudo attirail de sécurité qui va avec , serait t'il possible de le faire fonctionner, de l'activer en quelque sorte ?
J avais publié cet article il y a une quinzaine de jours, et l ai dépublié
Suite à un échange twitter avec un collègue geek , qui m'a indiqué que, peut être, le chiffrement était ultérieur à la génération des fichiers B2 par le logiciel médical + CPS + code porteur.
A défaut de sécurité "de base" lors de la fabrication des lots de factures, un chiffrement de transport rendrait les informations non captables sur internet.
J'ai donc fortement douté et j ai vérifié : j ai dans un premier temps appelé le Réseau Santé Social, et Orange Santé, qui m 'ont assuré du chiffrement de transport et de la sécurité des informations véhiculées.
On se dit qu'au minimum un simple SSL permettant de tunneliser est forcément utilisé, surtout quand on a acheté tout ce matériel, migré en 1.4, installé le kit de connexion et j'en passe..... ; puisqu 'un simple provider lambda propose cette option sans avoir besoin de l'attirail CPS....
Je leur ai demandé de me fournir un document contractuel décrivant leur offre de service : ce document n'existe pas ! et je me suis donc mis à douter encore plus.
Tout ce systême est très bien organisé pour ne pas être transparent : en effet les factures télétransmises ne sont pas consultables car les mails envoyés ne sont pas visibles, d'ou l'impossibilité pour l'utilisateur médecin ou professionnel de santé de se faire une idée de ce qu 'il envoie sur le réseau internet.
Le webmail n'est pas disponible, qui permettrait de voir ces envois et de connaitre l'étendue du chiffrement.
Deux solutions pour savoir : un proxy SMTP entre mon poste et mon FAI, ou l'analyse des trames réseaux avec Wireshark, j ai utilisé cette deuxième solution.
Sur le port SMTP après filtrage on obtient ceci lors de l'envoi d une FSE :
Avouez que ça a une bonne tête : les mails sortants de chez moi semblaient bien chiffrés.
Sauf que c'est marqué dessus, c'est en fait un simple encodage base64 permettant une vérification d 'intégrité, et non un chiffrement ( cf la RFC 4648 ) et là encore, la CPS reste inutilisée, alors qu'elle contient les clefs publiques nécessaires et suffisantes pour faire le job de chiffrement.
Après opération de décodage Base 64 ( qui peut se faire en ligne ici), je retrouve bien mon fichier B2 non chiffré, avec les données d 'identification en clair (nom du médecin, identifiant Adeli, numero SS et date de naissance du patient) et tout celà sort de mon ordinateur depuis 10 ans sans que je sois au courant.
Au final, la télétransmission des actes de médecine se décompose en deux opérations qui laissent les données personnelles et d'identification du patient et du médecin circuler en clair sur internet :
- l'une consistant en la fabrication des lots à télétransmettre dits B2
- l'autre consistant en l'envoi de cette facture B2 par internet sous forme d'un mail, pour lequel la CNIL préconisait déjà en 2007 un chiffrement de transport, qui n'est pas effectif dans la très grande majorité des cas (voire la totalité des cas, mais je n ai pu tester tous les FAI, seulement les "plus sécurisés") : ni VPN hardware qui partirait du modem routeur , ni même une petite cession SSL (et je ne sais pas ce qu'il en est pour les factures des cliniques, hôpitaux, laboratoires....).
Quelle conclusions à tout ceci et qu'exiger ?
- tout d'abord de la transparence et des engagements contractuels et écrits envers les professionnels de santé de la part des éditeurs, des transporteurs de flux, et du GIE sésam vitale, qui se foutent quand même un peu de notre poire quand ils nous causent chiffrement et sécurité avec la haute bénédiction ministérielle et la participation de tout ce monde à ce qui ressemble grandement à une mystification.
- les experts, le ministère, la CNIL n 'auraient t'ils rien vu ? un peu hilarant ou désolant, au choix.
- cette transparence doit pouvoir se matérialiser dans la visibilité des informations transmises sur le réseau par le professionnel de santé, ce qui n'est pas le cas aujourd'hui : je veux voir ce qui sort de mon ordinateur et qui va transiter sur internet.
Je suis au final un peu ébahi par ce systême, son coût, et son mode de fonctionnement totalement dégradé par rapport à ce qui nous est promis et vendu à l'heure ou n'importe quel provider SMTP est en mesure de fournir du SSL. (orange le fait avec les offres de base depuis le 5 mai 2011 par exemple).
Bien sûr un chiffrement intégral des FSE poserait de grands défis techniques, et il faut certainement un statu quo raisonnable (sans doute un layer SSL de transport, n'utilisant pas forcément les clefs publiques CPS) ; en passant je remarque que le prochain appel d 'offre CPS pourrait faire l'économie en deniers publics de toutes les fonctions non activées de la carte CPS.
Mais l'opacité, les inexactitudes et dans certains cas les mensonges qui entourent l'épopée sésam vitale, son obsolescence programmée en raison de l 'arrivée des technologies NFC sont tout de même extrêmement problématiques, et posent la question de la confiance que professionnels de santé et citoyens-patients-contribuables peuvent accorder aux discours rassurant et lénifiants des organisateurs de cette drôle de mystification collective.
On retombe sur les problématiques de l'expertise technique et de la démocratie, ou plus exactement de sa confiscation : chacune des organisations, éditeur de logiciel médical, GIE sésam vitale, ministère, industriel, organisme de normalisation (CNDA) a l'impression de faire au mieux et de ne pouvoir bouger le systême (qui nécessiterait des modifications techniques sur l ensemble de la chaîne) ; chacun a aussi de très bons arguments pour expliquer que rien n'est possible et que la responsabilité est celle d'un autre acteur de la chaine ; mais au final, le produit livré ne correspond absolument pas à ce qu'on est en droit d'en attendre ; si on interpelle les individus, chacun reconnait que le résultat final ne correspond pas à la communication réalisée par les organisations.
Se pose aussi bien évidemment la question de la confidentialité de notre travail, du secret dû au patient, d'un vieux truc qui ne semble plus d'actualité : le secret médical, et plus globalement du BigData et de la confidentialité des données personnelles.
Ci dessus un fichier B2 reconstitué : il s 'agit d'une trame réseau whireshark du port 25, décodée en base64 (car non chiffrée) et simplement copiée collée dans un wordpad.
En l ouvrant avec B2 viewer, on constate l'étendue des informations d 'identifications qui partent en clair sur internet : quel médecin a été consulté, quel jour, son numéro adeli, le numéro de SS et la DDN du patient, le montant facturé, entre autres.