Commentaires fermés sur BeID, la carte d’identité sous Linux, part 2, le terminal

Dans la première partie, j’ai expliqué comment installer les drivers pour lire la carte d’identité électronique belge ainsi que comment l’utiliser sous Thunderbird. C’était déjà pas mal mais ça serait un peu peu si c’était tout ce que savait faire cette foutue carte, non on peut s’amuser un peu avec. C’est pour cette raison qu’on est sous Linux non ?

Ce qui est beau, c’est que pour créer cette carte, l’on a utilisé des standards. Messieurs les concepteurs de systèmes, s’il vous plait, faites ça plus souvent ! C’est tellement mieux pour l’utilisateur (et surement plus facile pour vous aussi).

Pas mal de ces astuces viennent yobi.be, une belle mine d’info même si pas toujours très à jour. Le site est malheureusement down depuis quelques jours, j’espère que c’est temporaire mais sinon on peut toujours consulter l’archive ou faire revivre la page si quelqu’un a un wiki de libre.

eidenv

On commence par une simple mais marrante (et qui peut toujours servir). Le middleware vient avec la commande eidenv (un utilitaire de gestion de carte électroniques) qui affiche à la commande ceci :

$ eidenv | recode UTF8..
BELPIC_CARDNUMBER: 123456789012
BELPIC_CHIPNUMBER: 1234567890ABCDEF1234567890ABCDEF
BELPIC_VALIDFROM: 20.06.2007
BELPIC_VALIDTILL: 20.06.2012
BELPIC_DELIVERINGMUNICIPALITY: Liege
BELPIC_NATIONALNUMBER: 00310100123
BELPIC_NAME: Teuwen
BELPIC_FIRSTNAMES: Philippe Yvon
BELPIC_INITIAL: F
BELPIC_NATIONALITY: Belge
BELPIC_BIRTHLOCATION: Liège
BELPIC_BIRTHDATE: 25 AVRIL 1991
BELPIC_SEX: M
BELPIC_NOBLECONDITION: 
BELPIC_DOCUMENTTYPE: 1
BELPIC_SPECIALSTATUS: 0
BELPIC_STREETANDNUMBER: Rue de l'OpenSource 12 /b012
BELPIC_ZIPCODE: 1050
BELPIC_MUNICIPALITY: Ixelles

Ce programme est assez faible en fonctionnalité, mais il y en a une intéressante eidenv -x prog qui va exécuter prog avec les variables d’environnement précédentes.

Si votre fichier se compose de
#!/bin/bash
echo ${BELPIC_NATIONALITY}

L’exécution va donner

$ eidenv -x test.sh 2> /dev/null 
Belge

Allez cadeau: un créateur de vCard à partir d’une carte d’identité : eid2vcard.sh.

Pour les possesseurs d’une carte d’identité électronique estonienne (sait on jamais), vous pouvez jeter un œil à eidenv --stats pour voir quelques statistiques.

PKCS

PKCS ou Public Key Cryptographic Standards est un ensemble de spécifications créées par RSA labs pour la gestions des clefs. En voici 3 :

  • PKCS#11 défini ainsi une API pour utiliser des tokens pour l’authentification. Comme Firefox et Thunderbird utilise ce standard, c’est pour cette raison que l’on peut utiliser la carte avec ces deux programmes.
  • PKCS#12 est la norme pour le stockage de clefs. Si vous aviez exporté vos clefs dans Thunderbird, elles étaient stockées dans ce format. Et c’est également ce format que demande jSignPdf pour signer un document.
  • Finalement PKCS#15 permet de s’authentifier avec un token, indépendamment du fait que PKCS#11 soit utilisé ou une autre API.

Qu’est-ce qu’on peut faire avec ça ? Commençons par installer p11-kit et opensc et puis regardons ce qu’on peut trouver comme info. Par exemple avec opensc.

$ opensc-tool --list-algorithms
Using reader with a card: ACS ACR 38U-CCID 00 00
Algorithm: rsa
Key length: 1024
Flags: padding ( pkcs1 ) hashes ( )
$ opensc-explorer 
OpenSC Explorer version 0.12.2
Using reader with a card: ACS ACR 38U-CCID 00 00
OpenSC [3F00]> random 16
00000000: A7 EE 33 78 33 05 EA A6 7C 5C 54 2D 70 DA 83 38 ..3x3...|T-p..8

La commande pkcs11-tool ne fonctionnait pas chez moi (sans doute parce qu’ils utilisaient une version un peu modifiée du protocole) mais bien pkcs15-tool. On peut par exemple avoir le contenu de la carte

$ pkcs15-tool --dump
Using reader with a card: ACS ACR 38U-CCID 00 00
PKCS#15 Card [BELPIC]:
	Version        : 0
	Serial number  : 534C494E336600296CFF278CD00B1D2E
	Manufacturer ID: (unknown)
	Flags          : PRN generation, EID compliant

PIN [Basic PIN]
	Object Flags   : [0x3], private, modifiable
	ID             : 01
	Flags          : [0x30], initialized, needs-padding
	Length         : min_len:4, max_len:12, stored_len:8
	Pad char       : 0xFF
	Reference      : 1
	Type           : bcd
	Path           : 3f00

Private RSA Key [Authentication]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0x4], sign
	Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
	ModLength      : 1024
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : 3f00df00
	Auth ID        : 01
	ID             : 02

Private RSA Key [Signature]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
	ModLength      : 1024
	Key ref        : 131 (0x83)
	Native         : yes
	Path           : 3f00df00
	Auth ID        : 01
	ID             : 03

X.509 Certificate [Authentication]
	Object Flags   : [0x3], private, modifiable
	Authority      : no
	Path           : 3f00df005038
	ID             : 02
	Encoded serial : 02 10 1000000000000A6E5CEDB27CC97A20FD

X.509 Certificate [Signature]
	Object Flags   : [0x3], private, modifiable
	Authority      : no
	Path           : 3f00df005039
	ID             : 03

On voit que la carte utilise des certificats X.509 qui est une norme pour la gestion de chiffrement à clef publique (comme OpenPGP). Sachant ça, on peut utiliser openssl pour chiffrer quelques messages.

Je vous conseille de lire les manuels des outils pkcs, il y a de nombreuses fonctionnalités (explorer le contenu de la carte pour générez des bits aléatoires par exemple), une vous sera sans doute utile…

OpenSSL

OpenSSL est vraiment un programme très puissant et il nous le montre une fois de plus. Imaginons que vous voulez signer un message à envoyé à un ami en utilisant votre carte. Voici quoi faire :

$ openssl sha1 -binary msg.txt > msg.sha1 # hash du message
$ pkcs15-crypt --key 2 --sign --pkcs1 --sha-1 --input msg.sha1 --output msg.auth.sig
Using reader with a card: ACS ACR 38U-CCID 00 00
Enter PIN [Basic PIN]:

En plus du message et du fichier .sig, votre ami a besoin de votre certificat. On l’exporte comme ceci :

$ pkcs15-tool --read-certificate 02 > mykey.pem
Using reader with a card: ACS ACR 38U-CCID 00 00

Et pour finir, votre correspondant doit vérifier la signature par rapport à la clef publique

$ openssl x509 -in mykey.pem -pubkey -noout > mykey.pub
$ openssl dgst -sha1 -verify mykey.pub -signature msg.auth.sig msg.txt
Verified OK

Bingo ? Non !

Si vous êtes un peu parano, vous vous dites, « qu’est-ce qui me garantit que le certificat envoyé avec la signature n’est pas un faux ? » En effet un attaquant aura pu créer une clef à votre nom et l’utiliser pour signer le fichier. L’avantage d’utiliser les certificats de la carte d’identité plutôt que ceux que vous avez généré et que l’on a pas besoin d’échange de mallette diplomatique, car on a une chaine de signature.

$ openssl x509 -in mykey.pem -issuer -noout
issuer= /C=BE/CN=Citizen CA/serialNumber=200801

Mon certificat a ici été signé avec le certificat citizen avec le numéro de série 200801. Allons récupérer ce certificat sur repository.eid.belgium.be.

Attention, le fichier .crt n’est pas directement exploitable, il est au format DER (pour Distinguished Encoding Rules). Vous pouvez soit utiliser l’option export de firefox (pas trouvé comment faire avec chromium) lorsque vous examinez le certificat, soit convertir ce fichier avec openssl x509 -in citizen200801.crt -inform DER -outform PEM -out citizen200801.pem. On notera au passage qu’un site qui distribue des certificats et qui est même pas foutu d’utiliser SSL, c’est un peu se foutre du monde…

Ce certificat est signé par Belgium Root CA, donc il nous le faut aussi. Il suffira de rassembler tous les certificats de la chaine (ici belgiumrca et citizen200801) dans un fichier et puis vérifier la validité de notre clef en comparant avec le CA.

$ cat belgiumrca.pem citizen200801.pem > becitizenca.pem
$ openssl verify -CAfile becitizenca.pem mykey.pem
mykey.pem: OK

Maintenant on peut dire Bingo !

Voila un article pas mal plus technique et terminalesque que le précédent mais j’espère qu’il vous a plu quand même et que tout cela vous sera utile un jour (ou à défaut, était fun…). Si jamais je trouve d’autres info intéressantes, je ferai un troisième article mais je pense qu’on a fait le tour du plus important.

Depuis quelques années, en Belgique, l’ont peut déclarer ses contributions sur internet grâce à la carte d’identité électronique, alias eID. Que l’on aime ou non la numérisation de nos données, il faut avouer que le résultat est très intéressant. Non seulement la déclaration est devenue beaucoup plus facile que celle papier (pré-remplissage du formulaire, ça me prend 15min à tout casser) mais cette carte d’identité est équipée de certificats qui peuvent être utiles dans toute une série de choses.

Techniquement il s’agit de 3 algorithmes RSA de 1024 bits qui permettent la signature, authentification et répudiation. Les standards conseillent l’utilisation de clés de 2048 bits mais toujours est-il que le 1024 tient toujours bon à ce jour, croisons les doigts pour que ça dure encore quelques années le temps que la carte arrive a expiration et qu’on augmente le tout…
L’avantage d’utiliser ces clés plutôt que des que vous avez générer vous même est qu’elles ont été signées par le gouvernement belge. Elles sont donc une preuve solide de votre identité lorsque vous devez signer un document électronique, plus besoin d’échange de mallettes diplomatiques pour faire un échange de clefs efficace…

Ils ont l'air si heureux avec leur eid, on ne se fout surement pas de vous...

Tout d’abord là où j’ai été impressionné est la présence sur le site eid.belgium.be d’un middleware opensource (Google code), de packages pour Debian, Entreprise Linux, Fedora et Ubuntu ainsi qu’une doc assez fournie avec des détails techniques ou comment utiliser le tout avec Firefox, Thunderbird & Co (quoique les pdf semblent avoir bouger/disparut récemment, je me retrouve avec plein de liens morts). Pour une fois qu’on a pas été oublié, ça a le mérite d’être salué.

Beaucoup de choses mais un peu répartie n’importe où et pas non plus toujours très à jour. Voici donc quelques moyens de l’utiliser mais pour commencer comment l’installer sous Linux.

Installation

Sous Debian, les paquets beid-common, beid-tools et beidgui sont disponibles dans les dépots et semblent relativement à jour (version 3.5, la 4 est sortie en janvier).
Sous archlinux, il y a (comme d’hab) un package dans aur beid-svn mais qui ne contient que le Middleware, pas d’interface graphique. Après quelques recherches il semblerait que le beidgui va être remplacé par un applet mais il y a un petit laissé aller dans le développement.

Des autres paquets sont disponibles ici pour les distributions supportées, le guide pour Ubuntu est détaillé ici. Pour Gentoo, allez jeter un oeil ici. Ou tout simplement téléchargez les sources et compilez les…

Un des points important pour faire fonctionner le tout est d’installer les drivers de votre lecteur de carte. Vous pouvez connaitre votre modèle avec un simple lsusb et puis allez voir la compatibilité sur la page de cardreaders.be.

$ lsub
Bus 005 Device 002: ID 072f:90cc Advanced Card Systems, Ltd ACR38 SmartCard Reader

Mon lecteur étant un ACR38, j’ai installé le paquet libacr38.

Pour un rapide test que tout fonctionne bien, utilisez la commande suivante :

$ pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau
Compiled with PC/SC lite version: 1.8.1
Using reader plug’n play mechanism
Scanning present readers…

Belgium Electronic ID card

Tout va bien ici !

Thunderbird

Si vous voulez signez un mail avec votre carte voici comment configurer votre compte :

  1. Dans les paramètres du compte, allez à Security > Security Devices
  2. Sélectionnez NSS Internal PKCS11#Module, puis cliquez sur Load
  3. Entrez le chemin vers la librairie pkcs#11 (chez moi /usr/lib/libbeidpkcs11.so, dans la doc /usr/local/lib/libbeidpkcs11.so).
  4. De retour dans la fenêtre de sécurité, allez dans View certificates > Your certificates pour vérifier vos certificats. (Vous pouvez faire un backup)
  5. Dans Authorities > Belgium root CA > Edit trust, cochez « This certificate can identify mail users »
  6. Finalement, toujours dans la fenêtre security, choisissez un certificat pour Digital signing. Vous aurez le choix entre deux certificats : un certification « authentication » qui sert à signer simplement un mail et un certificat « signature » qui sert en cas de preuve pour signer des documents officiels & co, les deux sont valables.

Il n’y a pas de clef de chiffrement donc il est normal que l’on ne sache pas chiffrer de message (dommage mais bon). Maintenant que la configuration est faite, lors d’un envoi d’un mail, cochez la case Options > Digitally Sign This Message. Votre code PIN sera demandé (attention vous n’avez que 3 essais avant de la bloquer).

Il semblerait qu’il faille que votre correspondant ai importé le certificat Belgium Root CA, ils ne sont pas inclus par défaut dans Thunderbird. Ça se fait lors de l’importation de vos certificats ou peut être téléchargé ici) pour vérifier la chaine de signature (vous pourriez créer des faux certificats signés par un faux root CA). C’est un peu dommage mais déjà pas mal (les plus parano d’entre vous auront importés les certificats).

Le gouvernement belge ne connait pas votre adresse mail donc n'a pas pu la spécifier dans le certificat...

Les explications avec images sont disponibles ici (PDF, 700k).

Signez un document

En principe, vous êtes capable de signer un document avec Libre/OpenOffice via le menu File > Digital Signature et là sélectionnez votre certificat. Cependant, il n’y avait rien chez moi.

En principe, vous êtes capable de signer un pdf avec Adobe Reader via le menu Document > Security Settings > Digital ID et importer le fichier que vous avez créé si vous aviez exporté vos certificats (avec Thunderbird par exemple). Cependant ce programme est une bouse sans nom qui crash tout le temps, impossible d’en tirer quelque chose malheureusement.

Si quelqu’un a des solutions pour les signatures avec ces deux programmes, je suis preneur.

J’espère que ça vous aura été quand même utile, dans la prochaine partie, j’expliquerai quelques astuces à la ligne de commande (ou comment signer n’importe quel fichier avec son terminal).

Pacman 4.0 vient de passer de [testing] à [core] sur archlinux. Cette version apporte beaucoup de nouveautés mais surtout la signature des paquets.

Avertissement: si vous ne savez pas ce qu’est gpg ou le principe de signature, allez lire ceci, un peu vieux mais toujours aussi accessible et valable.

L’idée est de garantir, via la signature, que le paquet que l’on télécharge a réellement été créé par le développeur et qu’il n’y a pas eu modification (pour insérer une backdoor au milieu par exemple). Seulement on ne veut pas importer la clef publique de chaque développeur et la signer, ça serait inefficace et il faudrait les vérifier une à une si l’on voulait être sûr de sa validité (ce que franchement, personne ne fera). GPG utilise un système de web of trust pour la gestion des clefs qui revient plus ou moins à les amis de mes amis sont mes amis, vous ferrez confiance à une clef si elle a été signée par quelqu’un à qui vous faites confiance.

Archlinux possède plusieurs catégories de personnes dans la communauté : les développeurs (responsables pour [core] et [extra]), les utilisateurs de confiance (responsables pour [community]) et les master-keys. Pour qu’une clef soit acceptée, elle doit avoir été signée par au moins 3 des 5 master-keys. Chaque master possède un certificat de révocation pour la clef d’un autre master. Ainsi aucune de ces 5 autorités de confiance n’a un pouvoir absolu.

Pacman implémente donc désormais cette fonction de signature des paquets pour une sécurité accrue (et ça c’est bien). Si votre pacman est bien configuré au départ, ça ne changera quasi rien pour vous. Les seules différences seront lorsqu’il y aura un problème de sécurité (et vous serez alors content d’avoir configuré pacman somme toute). Pour faire une comparaison avec les autres packages manager, les autres implémentent d’habitude la vérification avec gpgv, qui suppose que toutes les clefs publiques importées dans votre keyring sont de confiance (bof) tandis que gpgme, utilisé dans pacman, supporte complètement le web of trust, si important pour ce genre de système. Les attaques les plus populaires sur les packages manager ont été empêchées avec, en plus, la signature des bases de données, la rétention de mise à jour sur des dépôts malicieux ou les flux de données sans fin (qui visiblement étaient possibles avant).

Par défaut la vérification des signatures est désactivé sur arch pour ne pas forcer à configurer le tout mais nous allons régler ça !

D’abord assurez vous que vous possédez bien la version 4 de pacman avec un simple pacman -Qs ^pacman$. Une fois fait (mettez à jour sinon, pacman -Rtt pour les paquets en conflits style package-query), commencez par générer les trousseaux de clefs nécessaires avec pacman-key --init, vous possédez maintenant une jolie clef de 2048bits.

$ pacman-key --list-keys
gpg: NOTE: trustdb not writable
/etc/pacman.d/gnupg/pubring.gpg
-------------------------------
pub 2048R/3D538099 2012-01-17
uid Pacman Keychain Master Key

Ouvrez maintenant le fichier /etc/pacman.conf (après merge avec pacman.conf.new généré à la mise à jour) et réglez les paramètres SigLevel pour chaque dépot. Ce dernier vaut par défaut Never, on a le choix entre deux valeurs acceptables Optional et Requiered. La première veut dire vérifiez la signature si présente, acceptez sans signature s’il n’y en a pas. Si ce paramètre est acceptable pour la transition, on ne veut pas le garder et le changer dès que possible pour Required (obliger la vérification). Par défaut, une clef ne sera acceptée que si on la juge de confiance (autorité de confiance a signé le certificat par exemple), on ne va pas changer ça mais si jamais vous vouliez le faire (pour une raison x ou y), rajoutez TrustAll sur la même ligne (à la place du TrustedOnly sous-entendu).

Attention, tous les dépôts ne sont pas encore entièrement signés ! Pacman 4 est stable mais il reste quelques détails pratiques sous arch pour assurer que tout est bien fait. Tous les paquets de [core] sont signés mais pas tous dans [extra] ou [community] et, de plus, les bases de données de ces trois dépôts ne sont pas non plus signées. En attendant que ce soit fait, on va donc être un peu moins difficile. Toujours dans pacman.conf, mettez Optional en global et pour les dépôts PackageRequired, Optional et Optional respectivement pour [core], [extra] et [community].

Si vous essayez de télécharger un paquet maintenant, cela vous sera refusé car vous ne faites pas confiance aux clefs gpg utilisées.

$ pacman -S ruby
resolving dependencies...
looking for inter-conflicts...

Targets (2): libyaml-0.1.4-1 ruby-1.9.3_p0-3

Total Download Size: 0.07 MiB
Total Installed Size: 20.16 MiB

Proceed with installation? [Y/n] y
:: Retrieving packages from community...
libyaml-0.1.4-1-x86_64 [#####################] 100%
(2/2) checking package integrity [#####################] 100%
error: ruby: key "FCF2CB179205AC90" is unknown
:: Import PGP key 9205AC90, "Eric Belanger ", created 2011-04-20? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

(Je la refuse car je n’ai pas envie de devoir faire ça un par un pour chaque développeur…)

Pour régler ceci, on va importer les clefs nécessaires. Si vous me faites confiance (attention il y a un piège), vous pouvez exécuter le script suivant (en tant que root).

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done

Ceci va importer les 5 master-keys nécessaires dans votre keyring et leur donner la confiance marginal (3 signatures marginales sont requises pour faire confiance à une clef). Cependant, il est conseillé d’aller vérifier chaque signature sur la page des mester-keys et de vérifier les fingerprints (pacman-key --finger des clefs. Bien sûr ça ne garantit pas que la page d’archlinux ai été hackée mais ça réduit déjà le risque.

Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Malheureusement on y est pas encore. Vous avez ainsi les master-keys qui sont bien importantes mais il vous faut encore importer les clefs des développeurs et des trusted users. Cela se fait rapidement via

curl https://www.archlinux.org/{developers,trustedusers}/ |
awk -F" '(/pgp.mit.edu/) {sub(/.*search=0x/,"");print $1}' |
xargs pacman-key --recv-keys

Notez que ce code ne fait qu’importer les clefs, on ne les signe pas. Tout l’intérêt du wot est justement de ne pas devoir signer les clefs des développeurs, si une clef d’un attaquant s’est glissé dans cette liste, ce n’est pas grave car elle n’aura pas été signée par les master-keys. Lorsque l’on télécharge un paquet, pacman vérifiera qui a signé le paquet, s’il se trouve dans notre keyring et est valable (3 marginal). Si ces conditions ne sont pas remplies, vous recevrez une erreur et il faudra y regarder. Cas 1: un nouveau développeur ou un possédant une nouvelle clef, vous pouvez l’importer, si elle est signée par 3 master-keys, ça passera. Cas 2: un attaquant a modifié une signature, importer la clef, elle sera refusée car invalide. De temps en temps (particulièrement si une mise à jour à échouée), vous pouvez rafraichir la base de donnée des clef via pacman-key —refresh-key.

Et vous voila avec un pacman bien sécurisé à l’abri des attaques principales sur la distribution de paquets ! Suivez bien l’actualité archlinux pour savoir quand demander la signature de base de donnée et passer de Optional à Requiered partout (bon par contre pour aur, on est pas prêt d’y arriver). J’espère que ça vous a été utile !

[Source]

CC XKCD

Un des gros problèmes d’android est les informations aux quelles une application a accès. Il y a bien un système de préférence mais souvent les gens n’y font pas attention ou font le pari que l’application n’aura pas de comportement malicieux. Le soucis est que l’on a que deux possibilités face à une application : l’installer et lui donner accès à tout ce qu’il demande ou ne pas l’installer. Assez rapidement, face à une application vraiment intéressante, la tentation de mettre de coté ses principes sécuritaires est très grande. Heureusement des développeurs de xda-developers ont trouvé la solution : PDroid.

PDroid est une application qui permet, pour chaque application individuelle, de choisir à quelles informations elle a accès. Pour chaque type de permission (ID de la carte SIM, numéro de téléphone, logs des appels,…) l’on a la possibilité de bloquer l’accès ou donner une valeur au choix. Il est aussi intéressant de noter que les applications ne crashent pas quand une permission leur est refusée (qu’ils disent, je sais pas comment ils s’y prennent). Un service très pratique en soit qui mérite d’être mieux connu.

Comme toute bonne chose sur smartphone, il faut avoir un accès root pour en profiter. Comme que le blocage se fait à un niveau assez bas (pour court-circuiter les appels à l’api android), il faut flasher la ROM pour la préparer à l’application. Comme expliqué sur le sujet sur xda, il faut appliquer un patch sur la ROM. Des patchs pour les ROM les plus populaires sont déjà fournis mais vous pouvez faire les votre facilement via un petit exécutable java. La procédure est décrite sur le thread en question. Étant donné que j’utilise une GeeksPhone, j’ai créé un patch pour CyanogenMod 7.1 pour le One et Zero.

Patch PDroid 1.25 CM 7.1 GP ONE
Patch PDroid 1.25 CM 7.1 GP ZERO

Mise à jour: au moins une nouvelle version de PDroid est sortie, je vous conseille de régénérer le patch vous même si vous en avez la possibilité (même si ceux ci sont tout à fait fonctionnels).

Pour patcher votre téléphone, mettez le .zip (en rapport avec votre ROM) sur votre carte SD, redémarrez en mode recovery (via ROM Manager ou autre) pour arriver sur le menu ClockworkMod, choisissez « Install zip from sdcard » > « choose zip from sdcard », sélectionnez le fichier et redémarrez une fois l’install finie. Allez ensuite télécharger l’application PDroid disponible sur le market.

Vous pouvez maintenant, pour toute application installée (y compris les applications systèmes), régler les permissions selon votre convenance.

Commentaires fermés sur La Belgique mauvaise eleve en securite informatique ?

C’est le blog OWNI qui rapporte l’info : les sites gouvernementaux belges et hollandais seraient globalement mal protégés en cas de cyberattaque.

Selon un rapport du Comité Permanent de Contrôle des Services de Renseignement et de Sécurité, la Belgique constituerait même « une cible idéale pour les attaques informatiques ».

Tout comme les Pays-Bas, un nombre grandissant de services administratifs peuvent être fait par internet en Belgique. Il est donc primordial d’assurer la sécurité de ces services.

Le plat pays sous les cyberattaques

css.php