Journal Les plans de la prison de Nancy étaient sur les 4 ordinateurs volés.

Posté par  (site web personnel) .
Étiquettes : aucune
2
9
mar.
2009
Bonjour

Je pense que vous avez vu passer l'info: 4 ordinateurs contenant les plans de la prison de Nancy ont été volés, par exemple
http://www.estrepublicain.fr/dyn/imprimer.php?link=/une/fran(...)

La prison devrait ouvrir entre le 22 et le 26 juin 2009.

D'un côté cela me fait marrer, d'un autre côté je me demande si cela va lancer un débat dans les hautes sphères de l'Etat...

Est-ce que le mot chiffrement va revenir à la mode ? Va-t-on avoir une prise de conscience de ces enjeux autour de la sécurité des données ?
Ca serait intéressant d'avoir une réaction d'un ministre (de la garde des Sceaux par exemple, ou de la ministre de l'Intérieur)...

  • # Et les formats?

    Posté par  (site web personnel) . Évalué à 3.

    Je vais faire mon Thierry S. en posant la question des formats de ces documents? Ouvert ou fermé? Car s'il faut un logiciel spécifique dans une version spécifique, ça limite les risques non? ;-)

    Sinon, je suis d'accord, ce vol est un exemple de plus illustrant l'importance du chiffrement...

    • [^] # Re: Et les formats?

      Posté par  (site web personnel) . Évalué à 6.

      Les plans dans le bâtiment c’est à 95% du .dwg de chez Autodesk.

      Évidement les machines possèdent le logiciel pour lire les plans, sinon c’est un peu con d’avoir les plans sans pouvoir les lire ;)

      • [^] # Re: Et les formats?

        Posté par  . Évalué à 7.

        Les plans dans le bâtiment c’est à 95% du .dwg de chez Autodesk.

        Tu veux dire 100%, je présume? ;)

        Rappel : le DWG est un des formats les plus difficiles à lire avec du logiciel libre. Quelques softs permettent d'importer certaines versions du format (ex. gvSig, dans une certaine mesure), mais c'est terriblement limité. Son équivalent destiné à l'échange, le DXF, est déjà un peu mieux supporté mais ça n'est pas encore la panacée. Le consortium OpenDWG, qui n'a d'ouvert que le nom, permet d'accéder à des librairies et exemples de code pas libres du tout (et rejoindre le consortium n'est pas donné). Cela permet d'avoir des logiciels non-Autodesk compatibles avec le format (et même une paire sous Linux), mais ça reste très très propriétaire. C'est, à mon sens, un des gros obstacles à l'avènement de Linux sur le poste de travail pro : quand on pense à la quantité de données qui ont été archivées dans ce format...

        Évidement les machines possèdent le logiciel pour lire les plans, sinon c’est un peu con d’avoir les plans sans pouvoir les lire ;)

        Sans ça, une visionneuse DWG, ça ne coûte pas bien cher.

        • [^] # Re: Et les formats?

          Posté par  (site web personnel) . Évalué à 2.

          Tu veux dire 100%, je présume? ;)
          non non … j’ai vu du MicroStation¹ mais c’est rare ;)
          Et je partage ton analyse sur le format :(


          Sans ça, une visionneuse DWG, ça ne coûte pas bien cher.
          0€ en téléchargement sur le site de AutoDesk et de Bentley. Je préfére celui de Bentley, celui proposé par AutoDesk est en .Net et il est inutilisable sans une machine (très) puissante.


          ¹ : http://fr.wikipedia.org/wiki/Microstation

          • [^] # Re: Et les formats?

            Posté par  . Évalué à 2.

            non non … j’ai vu du MicroStation¹ mais c’est rare ;)

            Oula, j'ai pas vu ça passer depuis une paye. Mais effectivement, je dois en avoir quelque-part au fin-fond d'un vieux disque. Vu comme on étiquetait les données à l'époque, je doute que ça me soit utile un jour, ceci dit.

            0€ en téléchargement sur le site de AutoDesk et de Bentley. Je préfére celui de Bentley, celui proposé par AutoDesk est en .Net et il est inutilisable sans une machine (très) puissante.

            Je confirme, le viewer d'ADesk est une usine à gaz (ou alors je confonds avec Design Review? Je ne sais plus tellement qui fait quoi, dans cette affaire).

        • [^] # Re: Et les formats?

          Posté par  (site web personnel) . Évalué à 7.

          Le consortium OpenDWG, qui n'a d'ouvert que le nom, permet d'accéder à des librairies et exemples de code pas libres du tout (et rejoindre le consortium n'est pas donné).

          Ahah ça m'a toujours fait marrer ces « OpenMachin » qui n'ont rien d'ouvert du tout... Ça mériterait qu'on crée un « ClosedDWG » qui propose des bibliothèques/docs/outils libres, rien que pour se moquer d'eux !

          • [^] # Re: Et les formats?

            Posté par  . Évalué à 3.

            Toi d'abord. Mais blague à part, si tu t'en ressens : vas-y fonce. Tu devrais avoir du succès (et des contacts réguliers avec le service juridique d'ADesk, avec un peu de "chance" :p )

  • # C'est déjà un peu le cas

    Posté par  . Évalué à 4.

    juste pour dire que la problématique est connue de plusieurs ministères. J'en connais plusieurs qui démarrent tout juste des projets sur le sujets (chiffrement de données : fichiers/répertoires ou bien disques entiers).

    c'est tard, mais c'est en cours. et ça fait un peu de boulot, ce qui n'est pas désagréable par les temps qui courent...

    • [^] # Re: C'est déjà un peu le cas

      Posté par  (site web personnel) . Évalué à 2.

      Est-ce que tu sais la ou les solutions retenues ? TrueCrypt ?

      ウィズコロナ

      • [^] # Re: C'est déjà un peu le cas

        Posté par  . Évalué à 2.

        Je ne connais pas le résultat des études ou éventuels appels d'offre (ou si je le connaissais, je dirais que je ne connais pas le résultat...)

        Mais pour répondre, oui TrueCrypt est souvent mentionné/étudié. Par contre plein d'autres produits sont étudiés et le critère libre/propriétaire n'est pas vraiment à l'ordre du jour...

        • [^] # Re: C'est déjà un peu le cas

          Posté par  . Évalué à 10.

          Par contre plein d'autres produits sont étudiés et le critère libre/propriétaire n'est pas vraiment à l'ordre du jour...

          Tu veux dire que le fait de chiffrer les données sans savoir comment c'est fait et donc sans être sûr de savoir les déchiffrer ne tracasse personne?

          Je sens que dans pas longtemps je ne me tracasserais pas vraiment de savoir que l'état détient des données sur moi.
          Au tribunal:
          -Monsieur, vous avez un casier judiciaire mais on ne sais plus l'ouvrir, est-ce que vous avez commis un vol dans les 10 dernières années? C'est pour savoir si on doit rajouter la récidive dans les circonstances aggravantes.
          -Euh...

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: C'est déjà un peu le cas

            Posté par  . Évalué à 4.

            Les logiciels de chiffrement propriétaires utilisés par les administrations sensibles doivent être certifiés par la DCSSI (en fait par un laboratoire agréé par la DCSSI).

            Je crois qu'à partir du niveau de certification EAL4+ le code source est fourni au certificateur. Par contre souvent seul le moteur cryptographique est certifié à ce niveau, et non la chaîne dans son ensemble. De plus il est assez facile pour un éditeur de distribuer une version différente de celle qui a été certifiée. Ce qui fait qu'un logiciel propriétaire peut effectivement dans la pratique faire à peu près ce qu'il veut...

            cf http://www.ssi.gouv.fr/fr/confiance/certificats.html

            Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

            • [^] # Re: C'est déjà un peu le cas

              Posté par  . Évalué à 3.

              Une question stupide sur la crypto,
              Mais j'imagine que soit c'est chiffré avec une passphrase
              qui doit être
              soit courte (<5 charactère) pour être mémorisée par le personnel et donc cassable en brute-force
              soit plus longue et dans ce cas là être notée dans les cahier/les agendas voir même avec des post-it sur l'écran
              Soit une vraie clée crypto stockée sur une clé USB ou une carte SD, qui doit certainement trainer dans les tirroirs du bureau.

              Bref en fouinant un peu il est possible de trouver comment acceder aux fichier crypté (évidémment ça demande une personne un peu familière des ordinateurs mais c'est pas un gros problème)

              A moins qu'il existe une méthode pour éviter ça ?

              • [^] # Re: C'est déjà un peu le cas

                Posté par  . Évalué à 2.

                La passphrase pourrait être sur un badge porté par l'utilisateur (mais le risque de perte est assez grand).

                Ou sinon, la biométrie ne serait-elle pas possible ?
                La passphrase serait donc l'empreinte digitale de l'utilisateur...
                Avec les avantages/inconvénients classiques de la biométrie.

                • [^] # Re: C'est déjà un peu le cas

                  Posté par  . Évalué à 5.

                  en général, le chiffrement est réalisé avec un certificat issu d'une PKI.

                  Le certificat peut être protégé de plusieurs façons:
                  - certificat logiciel protégé par passphrase : le niveau de protection le plus bas et le plus problématique en cas d'oubli de la passphrase
                  - certificat matériel (stocké sur une puce crypto): l'accès au certificat n'est possible que suite à saisie du code PIN. C'est plus sûr car l'attaque par brute-force est impossible (3 essais et c'est fini). ça n'empêche que le code PIN peut se retrouver noté sur un calepin/post-it. en général les utilisateurs sont sensibilisés à cette problématique mais ça reste des utilisateurs.
                  - certificat matériel sur une puce crypto protégé par biométrie : personne ne connait le code PIN de la carte. il est connu de la seule puce et n'est utilisé pour débloquer le certificat que si l'identification biométrique a réussi. (le PIN ne quitte jamais la puce)

                  petites précisions :
                  - on peut "vérifier" la biométrie de deux façon :
                  -- coté CPU mais on est pas à l'abri d'un soft malveillant se faisant passer pour un soft légitime, d'une écoute passive du câble USB qui relie le lecteur, etc.
                  -- coté puce. l'empreinte digitale (sa signature) est envoyée à la puce qui fait le travail de comparaison avec l'empreinte stockée. la réponse est un simple "oui" ou "non". C'est de loin le plus sûr.

                  d'autre part, pour devancer la question "et si le mec il part avec sa carte à puce ou s'il oublie le PIN ou s'il se fait bruler/trancher le doigt ? ou plus simplement encore si le certificat a expiré on fait comment ?". plusieurs approches sont possibles :
                  - le fait que le certificat soit issu d'une PKI permet le plus souvent d'avoir un mécanisme de recouvrement des certificats (séquestre de tous les certificats émis par exemple)
                  - le chiffrement est en fait réalisé avec un chiffrement symétrique (on va gagner en perf en plus) à l'aide d'une clé aléatoire et cette clé est chiffrée à son tour par la clé publique de l'utilisateur (pour qu'il puisse déchiffrer) mais aussi par la clé publique d'un certificat maître. Cette clé chiffrée deux fois indépendamment est fournie conjointement au document chiffré. Cela permet le recouvrement à l'aide de la clé privée de l'utilisateur mais aussi à l'aide de la clé privée du certificat maître.

              • [^] # Re: C'est déjà un peu le cas

                Posté par  . Évalué à 2.

                La passphrase longue, ça n'est pas vraiment un problème de mémorisation : du personnel rompu aux questions de sécurité en a généralement déjà l'habitude.

                Là où ça pose souci, c'est sur le long terme. Quand la passphrase de tel document est connue d'un seul utilisateur et qu'il part - à plus forte raison de manière brutale et imprévisible - c'est un document inaccessible à jamais. D'où l'intérêt de :
                - passphrase relativement génériques qu'on aura une chance de retrouver en cherchant un peu,
                - ou de noter les passphrases ici et là, pour plus tard.

                Et c'est là qu'on voit que, même dans les structures qui ont des besoins en matière de confidentialité (et qui se donnent les moyens de les satisfaire, parce qu'il y en a beaucoup qui "veulent" mais qui n'acceptent pas de mémoriser 8 caractères pris au hasard pour autant), il n'y a pas toujours de politique définie concernant les passphrases. Autant pour les mots de passe de session, on trouve assez souvent des règles raisonnables (genre ce qu'il y a par défaut sur un Active Directory, déjà), autant pour tout ce qui est "indépendant" c'est à la discrétion du chiffreur.

                • [^] # Re: C'est déjà un peu le cas

                  Posté par  . Évalué à 6.

                  À noter que, dans LUKS, par exemple, la clé symétrique de chiffrement est stockée dans une entête de la partition, ou de ce qu'il y a à chiffrer - elle est ensuite protégée par de la passphrase : je dis "de la", et non pas "une", car on peut tout à fait en mettre plusieurs, pour donner un peu de granularité aux accès.

                  Ainsi, sur ce qui doit être récupérable, les admins mettent leur "passphrase", et les utilisateurs en utilisent une autre - au final, c'est toujours la même clé symétrique qui protège les données (même si l'utilisateur n'y est jamais directement confronté), mais même si ses utilisateurs habituels ont perdue ou emmenée avec eux la "passphrase", pas grave : il reste celle(s) des admins, qui en profiteront pour désactiver celle qui s'est envolée dans la nature.



                  Après, le problème, c'est la taille de ce passe... mettons que le "standard" (de fait) de chiffrement symétrique est l'AES 256bits. Pour ne pas réduire le pool de possibilités que le bruteforçage devra affronter, ça nous fait donc une "passphrase" d'au moins 32 caractères ASCII (32*8bits). Dur de s'en souvenir... heureusement, on peut par exemple mettre ça sur un token crypto, en l'y stockant en tant qu'objet privé, uniquement accessible via un code PIN.

                  Il faut alors non seulement connaître le code PIN (la carte est censée se bloquer, et attendre une réinitialisation, après un certain nombre d'essais râtés), et posséder la carte (sans le PIN, le passe ne peut être extrait par des méthodes logicielles... reste la cryptoanalyse de la puce)... et là, ça devient humainement plus utilisable, tout en restant "sûr", et en permettant une granularité des accès aux données chiffrées.

                  Bon, sinon, on peut aussi stocker la clé symétrique directement dans le token crypto - ça évite de la laisser, même chiffrée, sur l'objet à protéger... par contre, ça complique les choses pour les accès multiples - ça dépend de ce qu'on veut faire, mais ça revient de toute façon peu ou prou au même, si le passe utilisé est long.



                  En outre, avec des tokens cryptos, on peut proprement faire de la PKI (Infrastructure à Clés Publiques), où les certificats couplés aux clés privées stockées dans les tokens vont rendre le tout très sûr : plus besoin de mot de passe (hors le PIN, qui est un peu plus qu'un passe, avec la répudiation après quelques essais manqués), hormis dans quelques cas, comme passer en superutilisateur (une fois authentifié avec le certificat, via SSH, par exemple), auquel cas, à la limite, on peut sortir un petit Kerberos juste pour ça (mais de toute façon, c'est loin d'être nécessaire pour tous les utilisateurs)... ah oui - et il y a Jabber, qui est chiant, aussi, avec ça (il semble qu'ejabberd2 va avoir le support de l'authentification TLS mutuelle... reste que je cherche encore un client libre qui permet ça).

                  M'enfin, si on a "des besoins en matière de confidentialité", et qu'on veut se donner "les moyens de les satisfaire", m'est avis que le plus simple, en matière de politique de mot de passe, c'est encore de les dégager le plus possible, pour les remplacer par de la PKI via des tokens crypto (en matière de confidentialité, c'est quand même bien sympa, ces petits artefacts, même quand on ne fait pas de PKI avec - pour le chiffrement, par exemple)... 5-6 chiffres à mémoriser, ça va : c'est quand même à la portée d'à peu près n'importe qui... Avec le PIN dans un agent, il n'y a même pas à le taper souvent.

                  Après, le soucis, c'est le support libre des tokens... ça marche avec OpenSSL, SSH, iceweasel... mais par exemple, sous KDE, c'est la loose - genre, avec Konqueror, nada... c'est moche, parce qu'Apache+TLS mutuel+Perl+LDAP, c'est pourtant de la tuerie (confidentialité et authentifications via TLS/X509, autorisations via X509 /ACL de l'annuaire - pas un mot de passe ou que ce soit - fonctionne en surcouche de tout ce qu'on peut/veut mettre sur le serveur web, ce qui permet de pousser les choses plus loin notamment dans l'appli web, avec par exemple du SASL proxy ou que sais-je encore) - et utiliser ça avec des clés en fichiers, c'est gâcher :(

  • # La solution

    Posté par  (site web personnel) . Évalué à 10.

    Je pense que la solution serait d'obliger les utilisateurs à installer un mouchard sur leur ordinateur. Ce mouchard permettrait à la police de vérifier que l'ordinateur ne contient pas de fichier volé. Ah mince, je crois qu'Hadopi y a pensé avant moi, je pourrai pas breveter l'idée :-(

  • # re:

    Posté par  . Évalué à 10.

    Si la prison est bien conçue, elle doit être sûre même si les plans sont divulgués non?

    • [^] # Re: re:

      Posté par  . Évalué à 8.

      Bah nan, regarde dans prison break, le mec il avait le plan, il s'est echappé.

      • [^] # Re: re:

        Posté par  (site web personnel) . Évalué à 7.

        Il suffit de faire quelques modifications dans l'emplacement des murs par rapport au plan et hop, le tunnel d'évasion débouchera dans le bureau du directeur !

      • [^] # Re: re:

        Posté par  (site web personnel) . Évalué à 5.

        Le problème c'est que son coup du plan, ça ne marche qu'une fois. Si on le transfère à Fleury-Mérogis, il va avoir l'air fin avec son plan de la prison machin.

    • [^] # Re: re:

      Posté par  (site web personnel) . Évalué à 10.

      C'est le principe de la sécurité par l'obscurité. Pour que la prison soit sécurisée ils vont éteindre les lumiere, comme ça les prisonnier pouront pas s'enfuir !!!

    • [^] # Re: re:

      Posté par  . Évalué à 5.

      Surtout si on passe le nouveau prisonnier tout tatoué au regard d'acier à la ponceuse.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.