• # Froid

    Posté par . Évalué à 3.

    Pas forcément besoin de refroidir, voir cette vidéo : http://fr.youtube.com/watch?v=JDaicPIgn9U (/!\ flashsapuecpaslibre)

    Le principe c'est que la RAM ne perd pas ses données immédiatement à l'arrêt de son alimentation, c'est juste l'agitation thermique qui "efface" les données.
    Alors oui en refroidissant on diminue les possibilités de perte de données mais même sans ça leur méthode fonctionne pendant quelques dizaines de secondes.
  • # pas forcément -196

    Posté par . Évalué à 5.

    -40/-50 suffit pour garder les données pendant 4 heures, dixit les chercheurs (voir explication très bien faite sur arstechnica
    http://arstechnica.com/news.ars/post/20080221-researchers-cr(...)
    ).
    Et -50 c'est relativement simple à avoir : eux ils utilisaient des "spray" d'air comprimé (utilisé pour nettoyer les clavier,...), mais dans les magasin d'électronique il existent aussi des spray dont le seul but est de refroidir à -50°c pour les recherches de pannes thermiques.
    (
    http://www.conrad.fr/givrant_kf_p_19500_19514_206919
    http://www.conrad.fr/givrant_freez_it_p_19500_19514_206917
    )
    • [^] # Re: pas forcément -196

      Posté par (page perso) . Évalué à 3.

      J'ai aussi appris y a pas longtemps que ces sprays pouvaient aussi servir à casser les antivols les plus solides, ceux en U, qu'on utilise pour les vélos ou les motos.
      Il paraît que le métal ainsi refroidi devient très cassant, puis un bon coup de marteau dedans, et c'est cassé.
      Du coup, y a des antivols en U qui sont censé résister à ça, m'a dit le vendeur, en me montrant les plus chers... :-(
  • # Parade

    Posté par . Évalué à 5.

    Boaf, "suffit" de copier /dev/urandom vers la RAM au moment du shutdown, non ?
    • [^] # Re: Parade

      Posté par . Évalué à 4.

      donc il "suffit" de débrancher le cable d'alim, d'enlever la batterie ou d'envoyer une commande de reset au bios pour contourner cette "protection" supplémentaire.
      • [^] # Re: Parade

        Posté par . Évalué à 6.

        Tu as raison, je n'y avais pas pensé. Il ne suffit pas de mettre n'importe quoi en RAM au moment d'éteindre la machine, encore faut-il l'éteindre effectivement.

        Je vais à l'instant aller me chercher un bon café, en n'oubliant pas de mettre hors tension mon ordina
    • [^] # Re: Parade

      Posté par . Évalué à 3.

      Une autre parade c'est de garder les données sensible le moins de temps possible en RAM.

      On peut aussi imaginer une fonction de verouillage du pc qui stocke la RAM dans un swap crypté et l'efface(en fait c'est un suspend to disk) qui est fait avant de quitter le PC ou au bout d'un timeout.
    • [^] # Re: Parade

      Posté par . Évalué à 3.

      Bah, la meilleure parade c'est de faire comme le gouvernement et l'armée du Royaume Uni, il suffit de ne rien crypter.
  • # facilement

    Posté par . Évalué à 3.

    facilement, facilement... c'est vite dit, il faut quand même avoir accès immédiatement à l'ordinateur. Malgré tout c'est intéressant à savoir cela, mais à mon avis cela ne va pas durer longtemps avant qu'une parade arrive (genre passage de la ram avec des 0 ou des données aléatoire à l'arrêt de l'ordinateur)

    Il est possible également d'encrypter la ram, en ce cas je ne sais pas si leur technique fonctionne toujours...

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: facilement

      Posté par (page perso) . Évalué à 1.

      Le nettoyage automatique de la ram à l'arrêt de l'ordinateur c'est facilement contournable, suffit de virer la batterie...

      Pour la ram chiffrée je veux bien, mais la clef elle est stockée où ? Dans un composant supplémentaire (c'est donc une protection matérielle) ?
      • [^] # Re: facilement

        Posté par . Évalué à 2.

        je ne sais pas, je ne suis pas cryptologue. Peut-être que l'on peut imaginer que la clé est stockée en mémoire et que cette zone mémoire est effacée en premier lors de l'arrêt de la machine.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: facilement

          Posté par . Évalué à 4.

          Justement le truc c'est que la machine est pas arrêtée, elle est débranchée.
      • [^] # Re: facilement

        Posté par . Évalué à 4.

        Pour la ram chiffrée je veux bien, mais la clef elle est stockée où ? Dans un composant supplémentaire (c'est donc une protection matérielle) ?

        Ca s'appelle TPM (ex TCPA) et c'est livrée en standard sur l'immense majorité des portables modernes. On en trouve aussi sur quasiment tous les PC de bureau à base de chips Intel.
        • [^] # Re: facilement

          Posté par . Évalué à 2.

          sauf que tpm a aussi des desavantages qui le rendent amha complètement inapte pour de la secu.

          voir mon commentaires plus bas ;)
  • # Une autre attaque

    Posté par . Évalué à 8.

    (pas réussi à retrouver de lien) j'avais entendu dire qu'un autre problème affectait les RAM : quand les données sont stockées longtemps à la même place physique dans la RAM (par exemple des clefs de chiffrement de disque dur), celle-ci s'use peu à peu et un léger dépôt d'oxyde se forme à l'intérieur, différemment si le bit est 0 ou 1.

    Sinon les attaques par des moyens détournés rappellent l'importance des principes suivants :
    1) avoir un algorithme cryptographique robuste est nécessaire
    2) avoir une bonne implémentation de cet algorithme l'est tout autant
    3) enfin maitriser le plus possible l'environnement dans lequel cet algorithme s'exécute est très important (carte à puce, salle de serveurs protégée, moyens de destruction rapide sinon du matériel, au moins des données... )

    À noter que les solutions "modernes" de type Hardware Security Module comportent des mécanismes de destructions de clefs en cas de changement trop brutal de la température.
    En général c'est pour protéger contre les attaques de type "Je fais chauffer la puce, comme ça elle fait des erreurs et j'en déduis de l'information sur le contenu", mais c'est également couplé à des mesures de protection physique comme "Si on tente d'ouvrir ça s'autodétruit".

    Malheureusement dans le domaine de la protection physique des moyens cryptographiques, la sécurité par l'obscurité joue à plein : souvent une implémentation physique est bien protégée contre certains types d'attaques, mais absolument pas contre d'autres. Les secrets industriels sont ici très utilisés.
  • # La parade !

    Posté par . Évalué à 10.

    Les graver sur un DVD contenant des oeuvres de Victor Hugo !
  • # l'interret ?

    Posté par . Évalué à 2.

    C'est quoi l'intérêt pratique de la chose ? Il n'est pas infiniment plus simple de lire la DRAM en fonctionnement ? (quitte a ecrire un driver noyau pour faire cela)

    "La première sécurité est la liberté"

    • [^] # Re: l'interret ?

      Posté par . Évalué à 2.

      Débrancher l'alim c'est plus simple que de se looger, d'accéder au noyau, d'insérer un module, ...

      En cas d'accès physique en tout cas.
      • [^] # Re: l'interret ?

        Posté par . Évalué à 3.

        Tu trouves plus simple l'extraction rapide des barrettes (sans se geler les doigts) pour les relires rapidement ? Dans une machine dediees d'ailleurs.

        "La première sécurité est la liberté"

        • [^] # Re: l'interret ?

          Posté par . Évalué à 4.

          Pas bien dur de piquer un portable, plus dur de passer root sur une machine en fonctionnement comme ça sans la rebooter ...
          • [^] # Re: l'interret ?

            Posté par . Évalué à 4.

            Surtout qu'à en croire leurs infos, on a un résultat similaire en rebootant sur un OS minimaliste (clé usb), lequel sera suffisament petit pour n'écraser que le minumum de RAM possible. Comme la RAM n'est pas initialisée au boot, il suffit ensuite à ce mini-OS de faire un dump de la RAM dans un endroit approprié.

            Un peu moins efficace que le passage au frigo, mais tellement plus pratique.
            • [^] # Re: l'interret ?

              Posté par . Évalué à 2.

              Comme la RAM n'est pas initialisée au boot,
              Tu oublis le bios qui remet la RAM à 0...

              C'est d'ailleurs ce qui empeche de recupérer des données d'un kernel panic. Par contre la RAM video n'est pas remise à 0.
              • [^] # Re: l'interret ?

                Posté par . Évalué à 2.

                Tu oublis le bios qui remet la RAM à 0...

                C'est loin d'être systématique, manifestement.

                Ce qui est remis à zéro de manière certaine, c'est ce qui est réutilisé par l'OS au reboot suivant.
  • # et aussi

    Posté par . Évalué à 2.

    http://www.engadget.com/2007/11/06/wiebetech-hotplug-lets-co(...) : passer un ordinateur du courant secteur à une batterie sans l'éteindre (lien dans les commentaires de http://lwn.net/Articles/270314/ )
  • # Il y a bien une solution...

    Posté par . Évalué à 3.

    mais elle a de SERIEUX inconvénients.

    Il s'agit des puces TPM, où la clé est censé ne jamais sortir...

    Inconvénients :
    - Mis en place de TCPA/Palladium/...
    - D'après la norme TCPA, le fabricant peut migrer d'un TPM à un autre toutes les clés, y compris les non migrables. => possibilité de récupérer les clés contenues dans la puce. -> Absolument nul si c'est implémenté.
    [section 13 , maintenance, de la norme https://www.trustedcomputinggroup.org/specs/TPM/tpmwg-mainre(...)
    spec retrouvé grace à a_capsi ]
    • [^] # Re: Il y a bien une solution...

      Posté par . Évalué à 4.

      D'après la norme TCPA, le fabricant peut migrer d'un TPM à un autre toutes les clés, y compris les non migrables. => possibilité de récupérer les clés contenues dans la puce. -> Absolument nul si c'est implémenté.

      C'est pas parce que tu migres les clefs, que tu as accès aux clefs. Déjà pour que les clefs soient migrables par le fabriquant il faut que l'endorsement key ait été activée en plein. C'est à dire mise en place ET non révoquée lors de l'initialisation du TPM ET associée à tous les profils.
      Ensuite on ne peut migrer les clefs que d'un TPM à un autre. On peut bien sur imaginer que le fabriquant est capable de construire un simulateur de TPM et de lire les clefs "en clair" dans la ram du simulateur.

      Les mécanismes de migrations sont nécessaires pour éviter que la mort d'une puce n'implique la mort de toutes les clefs associées à cette puce. Et il faut des droits assez élevés vis à vis du TPM ET vis à vis de la clef à migrer pour lancer une migration. Typiquement sur un TPM initialisé ou réinitialisé à la main, un fabriquant ne pourra migrer aucune clef sans l'assistance du TPM owner pour lui ouvrir les portes.
      • [^] # Re: Il y a bien une solution...

        Posté par . Évalué à 3.

        On peut bien sur imaginer que le fabriquant est capable de construire un simulateur de TPM et de lire les clefs "en clair" dans la ram du simulateur.
        Vu qu'on parle du fabricant, avec le rtl du code, il a même DUT en faire (ie , emuler la puce sur un fpga, avec la facilité de debug qu'offre un fpga).
        C'est donc même pas "on peut imaginer", c'est "il est forcé de le faire" (à 99.9%).


        un fabriquant ne pourra migrer aucune clef sans l'assistance du TPM owner pour lui ouvrir les portes.
        Tant que je n'ai pas de rapport de sécurité de la puce, j'évite d'être si affirmatif.
        On parle du CONCEPTEUR de la puce, pas du pekin moyen.

        Donc
        1°) un fabricant de puce TPM peut être considéré comme un attaquant niveau III : fond (presque) illimité et connaissance exemplaires.
        2°) rien ne l'empêche de mettre une backdoor style "autorisation owner ... ou tel clé", vu que par définition, c'est lui qui met ce qu'il veut dedans !


        Encore une fois, tu me sort un rapport de sécurité d'une puce TPM par un labo spécialisé dans ce genre de test, ok je pourrais avoir confiance.
        Mais croire que "le fabricant est quelqu'un de gentil" est une erreur dans le domaine de la sécurité.
        Surtout quand le fabricant vient de l'exterieur.


        Ps ne crois pas que je suis 100% contre le TPM, j'adorerais avoir un coprocesseur crypto sur lequel je puisse me fier, mais désolé la sécurité par l'obscurité (c'est proprio, on sait pas comment ils l'ont fait, c'est donc bon) ça n'a JAMAIS été de la sécurité.
        • [^] # Re: Il y a bien une solution...

          Posté par . Évalué à 2.

          On parle du CONCEPTEUR de la puce, pas du pekin moyen.
          En l'occurrence pour ma part là je parle de la norme. Il n'y a pas plus de raisons de faire confiance à une puce TPM qu'à une puce de carte bleue par exemple.
          Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation (nécessité d'ownership, nécessité de présence physique, validité des hashs etc.) ou de lire toutes les clefs en clair.
          En fait on peut toujours l'imaginer. On peut imaginer une backdoor dans les CPU qui permet de forcer les suites aléatoires à des valeurs prédéfinies, on peut imaginer une copie en zone cache de l'ensemble des opérations demandées aux fonctionnalités cryptographiques etc.

          Les CPU étant eux même proprios, on ne sait pas trop comment ils sont fait. D'après ton raisonnement il serait donc extrêmement dangereux de faire de la crypto avec.

          Evidement je prefererais que le specs du TPM soient libres. Elles l'étaient à une époque avant que que la levée de boucliers TCPA=Lagrande=Palladium n'ait lieu. Maintenant je reste persuadé que sur un PC surveillé raisonnablement (pas d'accès physique facile sur la machine pour un Intrus, surveillance des émissions réseau), TPM apporte un vrai plus. Bien sur on peut imaginer qu'à la demande de certains gouvernements la puce TPM ne soit pas tout à fait aussi inviolable que çà, auquel cas il faut faire des partages de secrets et rajouter des protections par dessus TPM.
          • [^] # Re: Il y a bien une solution...

            Posté par . Évalué à 3.

            Les CPU étant eux même proprios, on ne sait pas trop comment ils sont fait. D'après ton raisonnement il serait donc extrêmement dangereux de faire de la crypto avec.
            Les CPU ont comme but de stocker des clés, et d'éviter qu'elle puisse tomber entre n'importe quel main ?

            Non.


            On peut imaginer une backdoor dans les CPU qui permet de forcer les suites aléatoires à des valeurs prédéfinies
            Ce qui se remarque tout de suite. "Tiens c'est marrant, mais les valeurs de mon sha-256 ne correspondent pas à la norme (cas d'un générateur pseudo aléatoire par ex)."
            Sans compter que le CPU ne peut pas savoir si une suite de donnée c'est de l'aléas ou pas.

            on peut imaginer une copie en zone cache de l'ensemble des opérations demandées aux fonctionnalités cryptographiques etc.
            Fonctionnalitées qui connaissent pas les principaux CPU modernes (excepté le VIA). Et même si elles existent, tu peux toujours chiffrer en utilisant le CPU de façon "normal" sans recourir à leur instruction hard.


            Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation (nécessité d'ownership, nécessité de présence physique, validité des hashs etc.)
            Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".

            Regardons donc la norme TPM (et plus TCPA)
            :https://www.trustedcomputinggroup.org/specs/TPM/
            Maintenance is different from backup/migration, because maintenance provides for the migration of both migratory and non-migratory data. Maintenance is an optional TPM function, but if a TPM enables maintenance, the maintenance capabilities in this specification are mandatory – no other migration capabilities shall be used. Maintenance necessarily involves the manufacturer of a Subsystem.

            Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.

            Effectivement ils disent
            The owner and users of TCG platforms need assurance that the data within protected storage is adequately protected against interception by third parties or the manufacturer.
            ... en permettant une interception par le constructeur (ie puce tpm sur fpga).

            et comment ils comptent mettre ça en place ?
            Any maintenance process must have certain properties. Specifically, any migration to a replacement Subsystem must require collaboration between the Owner of the existing
            Subsystem and the manufacturer of the existing Subsystem. Further, the procedure must have adequate safeguards to prevent a non-migrational key being transferred to multiple
            Subsystems.

            Ah, on dis qu'on doit avoir une collaboration entre le possesseur et le constructeur, et qu'il doit y avoir des gardes fous... Sans plus de précisions!

            Après effectivement on peut imaginer que le fabriquant de la puce a une backdoor qui lui permet de passer au travers des 4 ou 5 mécanismes de sécurisation
            D'après le principes de conceptions : seulement 2 (dont 1 est automatique), le reste c'est du technique :
            Any migration of non-migratory data protected by a Subsystem SHALL require the cooperation of both the Owner of that non-migratory data and the manufacturer of that Subsystem. That manufacturer SHALL NOT cooperate in a maintenance process unless the manufacturer is satisfied that non-migratory data will exist in exactly one Subsystem. A TPM SHALL NOT provide capabilities that support migration of non-
            migratory data unless those capabilities are described in the TCG specification.



            Bref, comme je disais:
            - on autorise un gouffre.
            - on dis "mettez bien des barrières hein"
            => on dois avoir une entière confiance dans le constructeur.

            Si le standard TPM est bien respecté, ok... mais ce ne sera pas la première fois qu'une entreprise respecte pas complètement un standard pour son propre intérêt... et la on parle de sécurité, pas de "bien afficher une page web" !


            Bien sur on peut imaginer qu'à la demande de certains gouvernements la puce TPM ne soit pas tout à fait aussi inviolable que çà, auquel cas il faut faire des partages de secrets et rajouter des protections par dessus TPM.
            Je pense que je peux te rappeler le gouvernement chinois, et ses méthodes.
            Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.

            Si elle est vraiment inviolable, alors elle représente un vrai plus.

            Evidement je prefererais que le specs du TPM soient libres.
            Pas tant les specs que des véritables certifications de sécurité.
            Car si les specs ne sont pas respectée, c'est pas tellement plus cools.

            J'ai demandé ça à asus (une vérification de la sécurité de leur puce par un labo spécialisé), on verras ce qu'ils répondent.

            Pc : pour montrer que "on te cache tout" n'est vraiment pas une bonne politique de sécurité meme sur des puces, je t'invite à lire ce journal :
            https://linuxfr.org//~BlueBird/25926.html
            • [^] # Re: Il y a bien une solution...

              Posté par . Évalué à 2.

              Sans compter que le CPU ne peut pas savoir si une suite de donnée c'est de l'aléas ou pas.
              Les CPU modernes possèdent leurs propres générateurs aléatoires. Si ceux-ci sont plombés, il y a moyen de faire des trucs rigolos.

              Euh pas vraiment besoin, vu que la norme dis "il faut que des clés non-migrables soit migrables".
              Les psecs insistent aussi lourdement sur le fait qu'avant de lancer uen procédure de migration ou de maintenance le TPM doit s'assurer de la présence physique de l'opérateur.
              Ensuite les specs insistent aussi lourdement sur le fait que les clefs non migrables sont à usage strictement interne (en d'autres termes ce sont des clefs qui sont utilisés par le TPM pour le chiffrement en interne et elles ne doivent en aucun cas interagir avec des demandes de chiffrement ou du déchiffrement venant de l'extérieur)
              Toutes les clefs utilisables par les profils TPM sont migrables.

              Donc déjà on migre pas les clés "pour une sauvegarde", mais pour une maintenance.
              C'est normal, il s'agit ici de réinitialiser un TPM et de le remettre en état de marche. C'est le seul cas ou l'on peut avoir besoin de toucher aux clefs non migrables.

              on doit avoir une entière confiance dans le constructeur.
              Ou alors on casse l'init du TPM en enregistrant un endorsement key bidon (possible depuis TPM 1.2) et là même le constructeur ne peut plus rien pour nous d'après les specs. Il suffit ensuite de s'arranger pour ne jamais avoir à migrer des clefs non migrables. Pour cela il suffit de ne jamais utiliser les mécanismes d'authentification par tiers de confiance du TPM. A noter qu'à l'heure actuelle aucun fabriquant de TPM n'a mis en place de système d'authentification par tiers, s'en passer ne devrait donc pas poser de problèmes.

              Si la puce TPM "n'est pas si inviolables que ça", alors elle sert A RIEN.
              La puce TPM est un coffre à données. En tant que paranoïaque de première plutôt que de sauvegarder la clef privée chiffrée, protégée par mot de passe des liaisons SSL de mon serveur apache sur le disque dur, je décide de la rentrer dans un block TPM. A noter qu'il faut TOUJOURS que je tape mon mot de passe, simplement je n'ai accès au contenu de la clef que si je suis dans un environnement certifié. Si le TPM fonctionne bien : personne n'a accès a ma clef car elle n'est pas sur disque dur et qu'elle n'est disponible que si la séquence de boot convient au TPM. Si le TPM a des back-doors je me retrouve alors dans la même situation que si j'avais sauvegardé ma clef sur disque dur. En cas d'accès à mon disque dur, je n'ai plus qu'à prier que mon mot de passe résiste aux attaques.
              On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS. De fait je me sens plus en sécurité derrière un TPM. Maintenant je suis d'accord qu'il ne faut pas lui faire une confiance aveugle non plus.
              • [^] # Re: Il y a bien une solution...

                Posté par . Évalué à 1.

                Si le TPM fonctionne bien : personne n'a accès a ma clef car elle n'est pas sur disque dur
                Le chiffrement de dd ça existe... [c'était meme un peu le sujet de ce journal]

                et qu'elle n'est disponible que si la séquence de boot convient au TPM.
                Génial pour la rescue ça \o/
                Et ton ordi crash (mb défaillante) , tu fais comment? un RMA ?
                Si ton ordi crash avec un dd/svg chiffré ... ben tu change de pc, tu rentre le mdp / autre clé (smartcard ou autre) et hop tu à de nouveau accès à tout.
                Voir, comme proposé autre part dans ce thread, de la crypto distribuée.

                On peut imaginer que le nombre de gens ayant accès à la back door TPM est infiniment plus réduit que le nombre de gens ayant accès à la lecture du système de fichier EXT3 ou UFS.
                Et infiniment plus élevé que ceux ayant accès à une backdoor d'un dd chiffrée sérieusement ou d'une smartcard conçu pour la sécu et vérifiée comme il se doit par des labos indépendants.

                Pour moi, l'intérêt principal de TPM c'est de fournir un coprocesseur cryptographique , ie pouvoir chiffrer on the fly les dd en ayant presque aucune perte de perfs.
                • [^] # Re: Il y a bien une solution...

                  Posté par . Évalué à 1.

                  Pre mea culpa ;), vu que j'ai posté trop vite.


                  Quand je parlais de chiffrement du DD, je parlais bien entendu "avant que cette attaque soit révélé", ou alors du chiffrement du DD, mais non persistent (tu monte ton dd en chiffré, tu écris, tu démonte, tu attend n minutes pour que les clés n'existent plus. Sauf "storm" du gign à ce moment là... XD).
              • [^] # Re: Il y a bien une solution...

                Posté par . Évalué à 5.

                Les CPU modernes possèdent leurs propres générateurs aléatoires. Si ceux-ci sont plombés, il y a moyen de faire des trucs rigolos.

                Note au sujet des générateurs aléatoires à usage cryptographique :

                Un générateur aléatoire doit se composer de deux phases :
                1) l'initialisation par un aléa fourni par un générateur physique (ex : quantique, agitation thermique, temps d'accès disque, agitation de la souris/frappe au clavier, etc.)
                2) d'un retraitement algorithmique type chiffrement à flot qui va servir à fournir l'aléa à proprement parler.

                La phase 2), comme tous les algorithmes de cryptographie, se doit d'être totalement transparente et publique.

                En fournissant soi-même l'initialisation qui correspondrait au générateur physique, on peut facilement vérifier que les algorithmes sont correctement implémentés. En faisant des analyses statistiques rapides on peut se rendre compte que le générateur physique ne fournit pas des valeurs constantes, ou trop régulières.
                Étant donné que l'aléa physique ne sert pas beaucoup (initialisation et quelques ajout de temps à autre, pas souvent), on s'assure ainsi de la sécurité du générateur.

                En revanche, faire confiance à une solution clefs en mains est hasardeux : si on ne peut pas vérifier les algorithmes utilisés, rien ne garantit la sécurité du système en effet.
      • [^] # Re: Il y a bien une solution...

        Posté par . Évalué à 3.

        Les mécanismes de migrations sont nécessaires pour éviter que la mort d'une puce n'implique la mort de toutes les clefs associées à cette puce.

        C'est un (faux) problème, qui a été résolu de plusieurs façons :
        1) Chiffrer les clefs secrètes & privées utilisées avec la clef publique de quelqu'un d'autre en qui on a confiance, et ne lui donner le chiffré associé à déchiffrer qu'en cas de problème
        2) La cryptographie distribuée, où on peut partager un secret entre plusieurs personnes sans qu'elles n'apprennent rien dessus, tout en étant capable de le reconstruire dès qu'on récupère les informations auprès de chacun

        On peut ajouter que
        1) on ne sait pas avec précision dire quand une puce va mourir -> il faut migrer les informations suffisamment tôt
        2) une puce fonctionne en général parfaitement, ou bien elle est totalement morte (sauf analyse forensic poussée, ce qui n'est pas le cas ici vu qu'on s'intéresse à un fonctionnement normal et prévu) et donc une fois qu'elle donne des signes de faiblesse elle est en fait totalement morte

        Et conclure qu'il faut sécuriser les clefs en amont exclusivement, les dupliquer uniquement au départ le cas échéant et insérer la clef de fonctionnement une bonne fois dans la puce jusqu'à sa mort/la fin de la validité de la clef, et protéger les copies proprement. On ne devrait jamais avoir à récupérer une clef d'une puce une fois celle-ci en fonctionnement.
        • [^] # Re: Il y a bien une solution...

          Posté par . Évalué à 2.

          On ne devrait jamais avoir à récupérer une clef d'une puce une fois celle-ci en fonctionnement.

          À noter que ceci n'empêche pas une procédure "remise à zéro et insertion d'une nouvelle clef" (ou de l'ancienne si on voulait la récupérer). C'est juste le principe de vouloir pouvoir récupérer une clef qui est étrange et doit être mûrement réfléchi.
  • # Jolie démonstration mais...

    Posté par (page perso) . Évalué à 2.

    J'ai vu passer l'annonce de l'article sur le blog de B. Schneier [1] et je me dis que d'un point de vue scientifique, c'est intéressant (cela peut entrainer de la recherche et développement sur les mémoires) mais en ce qui concerne la sécurité informatique, il y a tout de même assez peu de cas où un malfaisant viendrait s'introduire dans des locaux, avec une bombonne d'azote liquide sous le bras et repartir avec une glacière ad-hoc.

    Si le malfaisant veut vraiment récupérer des données, il trouvera une possibilité moins ardue...

    Reste toujours un rempart contre ce genre de chose : la protection physique du matériel, donc ne nous affolons pas.

    [1] : http://www.schneier.com/blog/
    • [^] # Re: Jolie démonstration mais...

      Posté par (page perso) . Évalué à 2.

      Je peux te dire que dans une grande boite française, il y a plusieurs PC qui disparaissent dans les TGV chaque semaine. Simplement les types qui vont aux chiottes ou au wagon restaurant laissent leur PC.
      Dans ce cas, voler un PC allumé est facile.

      Multitasking — The art of doing twice as much as you should half as well as you could.

      • [^] # Re: Jolie démonstration mais...

        Posté par . Évalué à 1.

        sans compter que tu as juste besoin d'un spray, qui s'achète à conrad (cf deuxieme commentaire) pour une dizaine d'€

        Bref rien de vraiment voyant.

        Ensuite la copie de la ram, tu n'as pas besoin d'attendre les 4h, ca peut aller très vite (grosso modo la vitesse de ton support d'écriture)
      • [^] # Re: Jolie démonstration mais...

        Posté par (page perso) . Évalué à 6.

        il y a plusieurs PC qui disparaissent dans les TGV chaque semaine

        Oui, c'est quelque chose dont j'ai déjà entendu parler, mais là on revient à un vieux problème élémentaire : l'utilisateur est un boulet qui ne prend pas en compte la sécurité informatique (ou qui n'a pas été sensibilisé sur le problème).

        Le chiffrement des disques n'est pas une mesure permettant de pallier à cela (hélas).
      • [^] # Re: Jolie démonstration mais...

        Posté par (page perso) . Évalué à 1.

        Ca marche aussi en "suspend to disk"?

Suivre le flux des commentaires

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