À la découverte de l’écosystème Mooltipass

40
2
août
2020
Sécurité

Le projet open source Mooltipass a été lancé il y a maintenant sept ans, avec pour but d’offrir une solution hors ligne de stockage de noms d’utilisateur et mots de passe, de petits fichiers et de clefs SSH. Au contraire des solutions similaires existantes sur ordinateurs et téléphones, le Mooltipass est un élément dédié qui effectue seulement les opérations de sécurité. Composé d’extensions navigateur (Chrome, Firefox et Opera), d’un logiciel de gestion de bases de données multi‑plate‑forme et d’un appareil dédié branché en USB ou Bluetooth, nous vous faisons découvrir le fruit de sept ans de travail de contributeurs non rémunérés.

Mooltipass Mini BLE

Sommaire

L’appareil Mooltipass — principe de fonctionnement

Principe Mooltipass
Les trois appareils Mooltipass (Mooltipass Standard, Mooltipass Mini et Mooltipass Mini BLE) reposent sur le même principe de fonctionnement : chaque appareil contient une base de données chiffrée (AES‑256) par une clef contenue sur une carte à puce, elle‑même verrouillée par un code PIN (entré sur l’appareil). Comme avec les cartes bancaires, trois tentatives erronées bloquent indéfiniment la carte. Une telle solution permet ainsi à une personne d’utiliser plusieurs appareils, et à plusieurs utilisateurs de partager un seul appareil. La carte à puce peut être clonée, la base de données peut être exportée.
Pour éviter l’enfermement propriétaire (vendor lock‑in), l’équipe de Mooltipass fournit un script Python qui, avec un lecteur de carte à puce acheté sur le marché, permet de déchiffrer le fichier de sauvegarde d’un utilisateur.

Le Mooltipass Mini BLE — l’architecture interne

Architecture Mooltipass Mini BLE
L’équipe de Mooltipass lance en ce moment une campagne Kickstarter pour son dernier appareil : le Mooltipass Mini BLE. Comme tout le reste de l’écosystème, micrologiciel et matériel sont open source. Comparé à ses prédécesseurs, le Mooltipass Mini BLE se caractérise par une architecture basée sur deux microcontrôleurs : l’un est dédié aux communications externes (USB et Bluetooth), l’autre à la partie sécurité.

Le Mooltipass Mini BLE comprend aussi :

  • une mémoire Flash dédiée aux bases de données utilisateurs ;
  • une mémoire Flash dédiée aux ressources micrologicielles (graphiques, chaînes de caractères, mises à jour) ;
  • un écran OLED de 256 × 64 px monochrome ;
  • un adaptateur Bluetooth ;
  • une batterie NiMH pour une utilisation mobile.

Côté micrologiciel, le processeur « sécurisé » n’utilise que des bibliothèques développées par l’équipe de Mooltipass, à l’exception bien sûr des fonctions de chiffrement : la librairie BearSSL est ainsi utilisée. En se perdant dans les fichiers sources sur le projet GitHub officiel, vous pourrez ainsi trouver :

  • un format de stockage de fichiers (graphiques, chaînes de caractères, fichiers binaires, etc., et doc) ;
  • un format de stockage de base de données (doc) ;
  • une bibliothèque graphique avec gestion de la compression RLE et du tampon de trame (frame buffer).

À noter que le micrologiciel gère l’Unicode BMP et qu’il est possible de changer la langue de l’interface utilisateur (sont pour l’instant présents : anglais, français, allemand, italien, néerlandais, portugais, slovénien et finnois). L’équipe invite des contributeurs à rajouter des traductions en fournissant un fichier texte dédié.

Mooltipass Mini BLE — l’émulateur

Émulateur Mooltipass
Afin de faciliter les contributions, un émulateur de Mooltipass Mini BLE est disponible, pouvant être compilé sur Windows ou GNU/Linux. Celui‑ci est ensuite directement reconnu par l’écosystème, permettant de directement tester ce dernier.

Le logiciel compagnon — Moolticute

Moolticute
Moolticute est le logiciel compagnon du Mooltipass, compatible GNU/Linux, Windows et macOS, et entièrement libre. Il est écrit en Qt. Celui‑ci permet de :

  • gérer ses fichiers, noms d’utilisateur et mots de passe ;
  • exporter, importer et synchroniser sa base de données ;
  • paramétrer son Mooltipass ;
  • réaliser l’interface entre les navigateurs et l’appareil.

Moolticute

Il utilise une architecture réseau avec un démon qui s’occupe de la communication avec l’appareil et qui exporte un protocole simple via WebSocket aux différents clients. Le principal client est Moolticute, mais les différentes extensions des navigateurs l’utilisent également. Il existe aussi des outils en ligne de commande pour interagir avec ses identifiants, mc-cli, ou encore un agent SSH, mc-agent, qui fait le lien avec les clefs SSH stockées dans l’appareil.

Exemples :

moolticute-cli login get mywebsite.fr raoulh
mysql -u root -p=$(moolticute-cli login get mydb root)

Les extensions

Extension Mooltipass
Dernier élément de la chaîne, les extensions permettent à l’appareil de détecter automatiquement quand un couple nom d’utilisateur et mot de passe doit être enregistré ou entré sur une page. Lorsqu’une action est nécessaire, le Mooltipass vous invite à la confirmer directement sur l’appareil.
Il est aussi important de noter que le Mooltipass permet aussi de « simuler » un clavier, vous permettant ainsi via son interface de lui faire taper n’importe quel texte dans n’importe quelle application.

Compromis entre facilité d’utilisation et sécurité

Compromis entre facilité d’utilisation et sécurité
Convivialité et sécurité ne vont pas forcément toujours de pair, et c’est pourquoi le Mooltipass Mini BLE permet aux utilisateurs de paramétrer leurs préférences. Par exemple, vous pouvez choisir si vous aimeriez approuver chaque requête de nom d’utilisateur ou tout simplement laisser l’appareil faire son travail.
Les mises à jour des micrologiciels faisant l’objet d’une signature cryptographique, l’équipe espère ainsi pouvoir offrir de nouvelles fonctionnalités en fonction des contributions obtenues. Il est important de noter que l’appareil gère la nouvelle norme FIDO2/WebAuthn, permettant une identification à des services sans nom d’utilisateur ou mot de passe, en utilisant des challenges cryptographiques.

Aller plus loin

  • # J'hésite

    Posté par  . Évalué à 10 (+7/-0).

    Je trouve ça très intéressant, j'ai juste peur que ça ne soit pas si pratique que ça. Actuellement, j'utilise un keepass synchronisé sur mon téléphone et mon PC, du coup, j'ai tout le temps mes mots de passe avec moi. Là, ça voudrait dire prendre toujours avec moi un appareil en plus (et toujours penser à le prendre).

    « 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: J'hésite

      Posté par  . Évalué à 2 (+0/-0).

      Pareil, un keepass synchronisé régulièrement et une copie de sauvegarde dans un endroit différent, à l'abris et caché.

      • [^] # Re: J'hésite

        Posté par  . Évalué à 1 (+0/-0).

        Ma question va paraître bête et peut-être indiscrète mais où est synchronisé votre keepass ?

        Je sais que le fichier kdbx est chiffré mais je pense qu'il faut vraiment avoir confiance en l'hébergeur du fichier.

        • [^] # Re: J'hésite

          Posté par  . Évalué à 3 (+1/-0).

          Avec syncthing tu peux synchroniser différents appareils qui t'appartiennent quand ils se retrouvent sur le même réseau.

          Il est aussi possible de s'arranger avec un tiers de confiance (famille ou amis) dont tu sais que leurs compètences leur permettre de sécuriser le tout correctement.

        • [^] # Re: J'hésite

          Posté par  . Évalué à 2 (+0/-0). Dernière modification le 04/08/20 à 08:12.

          Ma question va paraître bête et peut-être indiscrète mais où est synchronisé votre keepass ?

          Le port non officiel android prend en charge de nombreuses source de données dont les grands clouds. J'utilise gdrive et j'ai une backup ailleurs dans le cas ou je ne peux pas accéder à gdrive dans la minute.

        • [^] # Re: J'hésite

          Posté par  . Évalué à 5 (+4/-0).

          Je sais que le fichier kdbx est chiffré mais je pense qu'il faut vraiment avoir confiance en l'hébergeur du fichier.

          C'est surtout en la robustesse du chiffrement du fichier qu'il faut avoir confiance. L'objectif est justement de ne pas avoir besoin de faire confiance à l'hébergeur.

          Ça nécessite aussi d'avoir un mot de passe très fort. Un point utile pour améliorer la sécurité si on n'est pas sûr de son mot de passe, c'est d'utiliser en plus un fichier clé. Il faut ensuite le synchroniser une fois manuellement sur tous les PC ayant besoin d’accéder au kdbx et de ne surtout pas le synchroniser sur l'hébergeur.

    • [^] # Re: J'hésite

      Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

      Pour ma part j'utilise bitwarden en (auto hébergé) j'en suis vraiment content, du coup j'ai viré keepass de toutes mes machines, android, pc, etc que je trouvais moins pratique en mode multi

    • [^] # Re: J'hésite

      Posté par  . Évalué à 1 (+1/-0).

      Hello

      J'utilise aussi un Keepass synchronisé, et j'hésite également à investir dans une solution autre.

      J'ai vu la clef Pastilda https://www.pastilda.com/ de Third Pin.
      - se connecte entre un clavier et PC (donc plutôt réservé à un PC fixe)
      - vu comme un clavier et une clef USB
      - une base Keepass est installée sur la clef USB
      - transmet normalement toutes les touches du clavier ; après une combinaison particulière, passe en mode "pastida"
      - le mot de passe maître de la base Keypass n'est jamais transmis au PC (sauf à l'initialisation de la base, je pense).

      Un point positif à mon sens, c'est qu'en cas de perte de la clef, il reste toujours possible d'utiliser Keepass (à condition bien évidemment d'avoir pensé à faire une sauvegarde de la base ailleurs), pas besoin d'outil spécifique.

      Cela dit, je ne suis pas certain que ça soit extrêmement pratique dès qu'on dépasse la vingtaine de mots de passe.

  • # Keepass + Inpustick

    Posté par  . Évalué à 10 (+11/-0).

    Bonjour,
    Je serais intéressé par un retour d'expérience sur un tel matériel.
    S'il est déchargé ou perdu, peut-on accéder à ses mots de passe par un autre biais ?
    Pour ma part j'utilise depuis quelques années Keepass sur Android avec un adaptateur physique Inpustick.
    On sait que les mots de passe longs, complexes, différents (pour chaque compte) et aléatoires améliorent la sécurité.
    Le soucis est que la saisie manuelle sur clavier finit par vite rebuter.
    L’adaptateur Inpustick est un récepteur sans fil (bluetooth + chiffrement 128 bits) qui se branche en USB.
    Il sera reconnu comme un clavier et une souris sur la machine où vous le brancherez.
    C'est pratique car il est reconnu sans pilote et cela même avant le chargement de l'OS: on peut ainsi mieux sécuriser son BIOS ou la clef de chiffrement matériel d'un SSD/HDD.
    Par exemple quand j'ai besoin de saisir un mot de passe, j'ouvre Keepass sur le mobile qui "injectera" le mot de passe directement vers mon PC, et je n'ai aucun logiciel à installer sur ce dernier.
    Pour la première mise en service on installe sur le mobile l'application InpustickUtility puis le plugin "KP2A" pour Keepass, un peu de configuration et voilà !
    Le prix est de 35 €, j'ai fini par en prendre un deuxième tellement c'est pratique (maison + travail).
    A noter que l'Inpustick ne stock rien, si vous le perdez vous aurez perdu le prix de son investissement - c'est tout.

  • # clé

    Posté par  . Évalué à 4 (+3/-0).

    Et ça peut remplacer une clé type yubikey, on peut mettre des clés pgp/gpg dessus et faire de la double autentification ?

    arnaud

    • [^] # Re: clé

      Posté par  . Évalué à 5 (+4/-0). Dernière modification le 03/08/20 à 13:12.

      Je partage un peu cette interrogation: quels avantages / inconvénients par rapport à une carte OpenPGP comme la Yubikey, combinée avec par exemple le logiciel pass (https://www.passwordstore.org/) ?

      A priori:

      1) avantages :

      • l'appareil contient la base de données. Pas besoin de la dupliquer d'un appareil à l'autre ou de la rendre accessible (avec pass+yubikey, il faut passer par un dépôt git ou copier les fichiers)
      • la saisie directe sur l'appareil évite de mettre en péril son code PIN si le système utilisé n'est pas sûr

      2) inconvénients :

      • l'alimentation nécessaire pour l'appareil est plus importante qu'une Yubikey. Cela interdit a priori l'utilisation du NFC, qui est pratique sur les mobiles
      • l'appareil est moins polyvalent : pas moyen de l'utiliser pour les opérations PGP de signature, déchiffrement, etc…
      • il est aussi plus encombrant

      Nb :
      Avec pass + yubikey, j'utilise un petit dépôt git (autohébergé) pour rendre disponible les fichiers de pass et les synchroniser entre mes différents appareils (mobile, ordinateur portable, etc…). Ca marche bien, mais la mise en place est un peu lourde.

      Nb2: outre le code pin de déverrouilage, la yubikey possède également un "bouton" capacitif qui permet de rendre obligatoire un accès physique à la clé à chaque usage, tout en étant ultra rapide, ce que je trouve à la fois pratique et sécurisant

      • [^] # Re: clé

        Posté par  . Évalué à 2 (+2/-0).

        Je suis d'accord avec vos points… cependant nous espèrons qu'à l'avenir nous pourrons avoir le temps d'implémenter les fonctionnalités PGP sur l'appareil (ou peut être un futur contributeur?).
        Une rapide remarque qu'avec une yubikey, vous ne savez jamais ce que vous approuvez avec certitude…

        • [^] # Re: clé

          Posté par  . Évalué à 1 (+0/-0).

          Puisque tu semble faire parti du projet. Je n'arrive pas à trouver les sources de la partie carte à puce, ni même de quel SE il s'agit, avec quelle application. Tu aurais des pointeurs (ou à defaut des infos) ?

        • [^] # Re: clé

          Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

          cependant nous espèrons qu'à l'avenir nous pourrons avoir le temps d'implémenter les fonctionnalités PGP sur l'appareil (ou peut être un futur contributeur?)

          Je ne sais pas quel microcontrôleur vous utilisez (je n’ai trouvé cette information nulle part sur votre site, et je ne sais pas interpréter les fichiers disponibles dans le dépôt minible_hw), mais pour information, il existe une implémentation complètement libre de la carte OpenPGP pour contrôleur STM32F103 : Gnuk.

          (Je n’ai pas la moindre idée de l’effort que demanderait le portage de cette implémentation sur le contrôleur du Mooltipass, si ce n’est pas un STM32…)

          • [^] # Re: clé

            Posté par  (site Web personnel) . Évalué à 2 (+2/-0).

            Je ne sais pas quel microcontrôleur vous utilisez (je n’ai trouvé cette information nulle part sur votre site, et je ne sais pas interpréter les fichiers disponibles dans le dépôt minible_hw)

            Pareil, je me demande bien ce qu'ils utilisent, surtout pour le "secure MCU".

  • # Qui de la mobilité ?

    Posté par  . Évalué à 1 (+1/-0). Dernière modification le 03/08/20 à 11:05.

    L'outil et le concept semblent prometteurs.
    Qu'en est il en mobilité ? Si je veux accéder à mes mots de passe sur téléphone, puis je connecter le device en usb et accéder aux identifiants ?

    [Edit] Commentaire envoyé trop vite, leur site mentionne un usage sur smartphone avec une démonstration ici : https://www.themooltipass.com/ressources/android.mp4

  • # Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

    Posté par  . Évalué à -3 (+7/-6).

    Ayant lu la dépêche et tous les commentaires publiés à cette heure, il me semble opportun de faire quelques rappels sur un enjeu de sécurité souvent négligé : la question de la conformité des opérations numériques effectuées par des dispositifs matériels de conception non ouverte, ou bien de conception ouverte mais non fabriqués et livrés sous supervision.

    Un dispositif numérique aux schémas libres, mais fabriqué et livré sans supervision, ne garantit pas beaucoup mieux cette conformité qu'un dispositif propriétaire aux schémas non publiés. En effet, il est possible que soient présentes des failles de sécurité matérielles (y compris des failles intentionnellement placées) dans le ou les processeurs du dispositif (voire dans des composants réputés passifs, en poussant loin l'hypothèse d'une malveillance très élaborée). Il existe donc un risque de vol des données sensibles du dispositif, par exemple des mots de passes et des clés de chiffrement, y compris un vol à distance, particulièrement lorsqu'on utilise le dispositif en le branchant à un ordinateur relié au réseau.

    Ci-après, je présente dans une première section un cas d'usage mettant en évidence les limites de la confiance obtenue par une analyse de surface d'un circuit imprimé et d'une puce. Dans la section d'après, je décris quelques principes de rétro-ingénierie d'une puce, montrant ainsi la complexité du processus destructif permettant d'obtenir un haut niveau de garantie de la conformité des opérations numériques pouvant être effectuée par ladite puce avant sa destruction… Ensuite je fais un rappel sur les conditions d'un haut niveau de garantie de conformité. Je finis en mentionnant le projet Libre Silicon.

    [ Le cas du Ledger Nano (matériel non libre) en exemple : les limites de la confiance obtenue par une analyse de surface ]

    Je prends l'exemple d'un porte monnaie électronique, typiquement une clé USB constituant un ordinateur en soi, protégée par un code PIN, qui stocke les clés, ayant vocation à être connectée à une une machine liée au réseau, cf. par exemple le « Ledger Nano » (et « Nano S ») qui, bien que n'étant pas un matériel aux schémas publiés, constitue un support d'étude significatif relativement à la possible présence de failles de sécurité matérielles.

    Dans une émission audio francophone dédiée à la cybersécurité, disponible sur le site web NoLimitSecu — l'émission titrée « Sécurité dans l'écosystème des cryptomonnaies - NoLimitSecu », publiée en septembre 2017 — il est expliqué (à 1h02) que la meilleure solution à l'heure actuelle en tant que porte monnaie électronique est d'avoir un système physique qui signe les transactions hors ligne : une clé USB protégée par un code PIN et qui stocke les clés, et dont les clés ne sortent jamais. On branche la clé USB au moment de faire la transaction. Le montant et l'adresse de la transaction s'affichent sur le petit écran de la clé USB. On valide physiquement en cliquant sur un bouton. Dans ce système, la clé de chiffrement privée reste dans une enclave, non accessible depuis l'extérieur. On dispose par ailleurs d'une phrase de passe en cas de vol ou de dysfonctionnement de la clé, qui permet de reconstruire la graine et de réinstaller la graine sur une autre clé. Il suffit juste de garder ce petit papier physiquement dans un coffre (ou dans une banque nous dit un des intervenants, je tousse…). Ex. conseillé : Ledger Nano (ou Nano S), Ledger étant une start-up française.

    Dans la vidéo (en français), publiée le 14 janvier 2020 sur la chaine Youtube « Deus Ex Silicium » (gérée par Stéphane Marty, ingénieur en micro-électronique), titrée « Deus Ex Silicium : Que vaut l’électronique d'un portefeuille de cryptomonnaie LEDGER NANO S ? », on peut assister à une analyse de surface du circuit imprimé garni de composants, ainsi qu'à une analyse de surface au microscope optique (grossissement jusqu'à environ 800 fois) de la puce du crypto-processeur (dédié aux traitement cryptographiques), la puce étant d'abord extraite de son boitier. L'analyse effectué est une analyse de surface en ce qu'elle ne consiste pas en une rétro-ingénierie du dispositif, particulièrement de ses différentes puces. Seule une analyse (destructive) de l'intérieur de toutes les puces, par érosion progressive et auscultation détaillée des multiples couches de conducteurs métalliques empilées, jusqu'à la couche de silicium dopée localement, le tout avec un microscope électronique à balayage, suivie d'une analyse détaillée de la conception, pourrait garantir la validité de la conception et l'absence de faille de sécurité ou de malveillance consciemment intégrée (comme une porte dérobée).

    [ Description de quelques principes de rétro-ingénierie d'une puce ]

    Par ailleurs, Stéphane Marty donne en vidéo des explications sur les méthodes qu'il utilise pour accéder à la puce de silicium initialement enrobée de polyépoxyde de couleur noire (généralement sous forme de boitier comportant des pattes métalliques pour le relier électriquement au circuit imprimé). Dans la vidéo publiée le 20 octobre 2014, tirée « Deus Ex Silicium : Méthodes pour extraire un circuit intégré », il présente notamment la technique de dissolution du boitier en polyépoxyde grâce à un bain d'acide sulfurique concentré à 96% et chauffé à 150°C.

    L'accès à la puce permet une analyse de surface par microscopie optique, mais cela ne révèle que la première couche de métal, voire les deux premières, par transparence, or il y a typiquement plusieurs couches de conducteurs métalliques (il peut y en avoir 7, par exemple, sur un processeur, avec parfois une couche de surface dont la fonction est de masquer tout le reste, comme dans certaines cartes à puces). Ces couches sont empilées au-dessus du substrat en silicium (qui est dopé localement en ions positifs ou négatifs, dans son épaisseur, pour constituer des transistors).

    Dans la vidéo — URL calée ici à 6'48" — publiée le 29 octobre 2014 sur la même chaine Youtube, tirée « Deus Ex Silicium : Décortiquer une carte a puce bancaire », l'auteur mentionne l'usage d'un acide qu'il appelle « acide hydrofluorique » pour dissoudre les couches de conducteurs métalliques. En fait, il fait référence à l'acide fluorhydrique qui, je cite un extrait de la section Description du lien précité, « a la propriété unique de pouvoir dissoudre presque tous les oxydes inorganiques, ainsi que la plupart des métaux (seuls le platine, l'or, l'argent et le mercure ne sont pas attaqués) ».

    L'audit intégral d'une puce de circuit intégré est un processus destructif qui concerne uniquement l'échantillon analysé (les autres échantillons du même modèle déclaré peuvent éventuellement avoir une conception au moins légèrement distincte, ce qui constitue alors une tromperie). Un tel audit est extrêmement délicat et laborieux : il nécessite déjà d'éroder couche après couche, avec de l'acide fluorhydrique, les couches de conducteurs métalliques de la puce. Cette opération nécessite un savoir-faire peu répandu et une habilitation spécifique pour obtenir et manipuler légalement cet acide en France. Il s'agit alors d'effectuer une auscultation minutieuse au microscope électronique à balayage pour chaque couche distincte révélée, jusqu'à la couche du silicium. Le microscope électronique à balayage peut y compris permettre de révéler le signe, positif ou négatif, de polarisation des zones dopées en ions, donc d'extraire le schéma intégral de la puce. L'audit doit se poursuivre par l'analyse du fonctionnement de la puce via une modélisation numérique et une étude théorique facilitée par une simulation numérique.

    En passant, un tel audit intégral doit pouvoir faire l'objet d'une automatisation très poussée (avec une robotisation très fine pour l'érosion à l'acide et la captation des images au microscope électronique à balayage, d'une part, et avec une IA très élaborée pour aider à l'analyse théorique du schéma obtenu, d'autre part), mais je n'ai pas connaissance de l'état de l'art en matière d'automatisation de ce processus.

    [ Rappel sur les conditions d'un haut niveau de garantie ]

    Pour réduire drastiquement le risque d'inclusion malveillante de failles de sécurité au niveau matériel dans les dispositifs numériques, il est impératif, in fine, de disposer d'une conception détaillée ouverte (idéalement sous licence libre), auditée, faisant idéalement l'objet de preuves formelles couvrant le maximum de surface du code de définition matérielle, et d'une supervision de la fabrication et de la livraison.

    Les preuves formelles peuvent être produites à plusieurs niveaux, par exemple des preuves formelles de conformité de la conception détaillée par rapport aux spécifications, ainsi que des preuves formelles de résistance de la conception à des classes d'attaques (exploitant des failles de sécurité matérielle) répertoriées, documentées, et elles-mêmes spécifiées formellement. Notons que la couverture totale par des preuves formelles est théoriquement impossible dans certains cas, l'informatique s'appuyant sur les mathématiques et les mathématiques comportant des énoncés considérés comme parfaitement justes et pour lesquels il est prouvé qu'ils sont indémontrables (ils sont dits « énoncés indécidables »).

    La supervision des étapes de fabrication et de livraison peut être obtenue avec différents niveaux de sécurité. J'évoque ici quelques pistes pour l'étape de fabrication :

    • un premier niveau de supervision peut impliquer la délégation d'assesseurs techniques (par exemple tirés au sort avec stratification statistique au sein d'une communauté de spécialistes) auprès d'un industriel qui accepte leur présence par contrat, les assesseurs ayant à disposition des capteurs permettant d'automatiser au moins partiellement la supervision ;
    • une autre approche consiste à analyser un certain nombre d'échantillons de puces produites en sortie d'usine (analyse nécessairement destructive) pour obtenir une estimation probabiliste de la conformité aux spécifications du reste de la production ;
    • au plus haut niveau de sécurité, la supervision de la fabrication se fait par la création d'une usine dédiée, opérée sous contrôle d'assesseurs technique mandatés, impliquant au moins la présence de capteurs sécurisés (chaque information produite par un tel capteur fait l'objet d'une signature numérique, le capteur étant conçu pour saborder sa clé interne de signature en cas de tentative d'intrusion en son sein) pour vérifier les résultats du processus de fabrication à chaque étape (les machines impliquées dans la fabrication proprement dite ayant été acquises auprès d'industriels tiers, la méfiance s'impose), et impliquant au mieux un processus d'amorçage de la conception jusqu'à la racine de la fabrication, c'est à dire en concevant et fabriquant les machines elles-mêmes dédiées à la fabrications des puces voulues.

    Je préconise l'adoption de l'expression consacrée « matériel authentiquement libre et contrôlé » pour me référer à ce type de protocole de conception / fabrication / livraison. Le mot authentiquement renvoie à la disponibilité d'absolument tous les détails de conception ; le mot contrôlé renvoie aux audits, aux preuves formelles, et à la supervision de la fabrication et de la livraison.

    [ Rappel sur l'existence du projet Libre Silicon ]

    Pour rappel, il existe un projet nommé Libre Silicon (lien vers le site web officiel) visant à permettre de fabriquer des puces avec des moyens techniques et des objectifs de miniaturisation et de performance plus modestes que les gros industriels, avec une logistique minimaliste et par là transportable, et surtout avec des outils logiciels de pilotage de la fabrication qui soient libres. Cf. ce commentaire, particulièrement la première section (tirée « [ Situation du projet LibreSilicon (fabrication avec des outils logiciels libres) ] ») et la dernière section (tirée « [ Principes de résistance à une cyber-attaque systémique au plan du matériel ] »).

    • [^] # Re: Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      TL;DR

      Je préconise l'adoption de l'expression consacrée « matériel authentiquement libre et contrôlé » pour me référer à ce type de protocole de conception / fabrication / livraison. Le mot authentiquement renvoie à la disponibilité d'absolument tous les détails de conception ; le mot contrôlé renvoie aux audits, aux preuves formelles, et à la supervision de la fabrication et de la livraison.

      Pour rappel, il existe un projet nommé Libre Silicon

      vala ça c'est fait ;-)

      • [^] # Re: Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

        Posté par  . Évalué à -10 (+0/-6).

        En positif, merci d'avoir donné un tout petit peu de visibilité, par ce très bref résumé, à l'aspect essentiel de mon long message détaillé et sourcé qui ne connaitra visiblement pas l'indexation par les moteurs de recherche et restera replié (et non dépliable au sein de la page) donc invisible pour les lecteurs pressés (ou simplement non éclairés des techniques de navigation sur le site).

        Je vais m'abstenir pour un temps de donner de la confiture… publier sur Linuxfr.org en fermant le présent compte. Bon courage à l'équipe d'administration du site pour concocter une équation au sujet du karma qui puisse contenter les « moinseurs » patentés, dont les sionistes adeptes du « ni pardon, ni oubli » (et pratiquants de l'inversion accusatoire), le restant des personnes insincères et perverses, souvent formatées idéologiquement et se prétendant émancipées, le troupeau des moutons, et la troupe grandissante de ceux qui se réveillent chaque jour un peu plus dans la matrice oligarchique (ceux-là ont jeté le masque prétendument anti-covid pour cet été, sauf situation d'obligation légale orwellienne).


        Parce que j'aime parfois finir proprement le travail, voici quelques corrections typographiques (en gras) apportées à mon texte ci-avant, à toute fin utile (s'il en est qui veulent s'en inspirer) :

        • [accord en nombre] « aux traitement cryptographiques » est à corriger ainsi : « aux traitements cryptographiques »
        • [accord en genre] « L'analyse effectué » est à corriger ainsi : « L'analyse effectuée »
        • [accord du pronom] « Je préconise […] pour me référer » est à corriger ainsi : « Je préconise […] pour se référer »
        • [suppression d'une redondance] « connectée à une une machine » est à corriger ainsi : « connectée à une machine »
        • [accord en nombre] « la conformité des opérations numériques pouvant être effectuée » est à corriger ainsi : « la conformité des opérations numériques pouvant être effectuées »
        • [^] # Re: Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

          Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

          fais gaffe : samwang-13 — ton prochain pseudo — risque de ne pas te porter plus de chance, même si tu n'es pas superstitieux car ça porte malheur :p

          bref, j'espère ne pas avoir trop trahi ton propos, j'ai essayé d'en extraire ce qui m'en paraissait les 2 points intéressants (et je ne t'ai pas moinssé : je surfe à -42 de toute façon et je préfère relever le positif plutôt que sanctionner tes logorrhées que je prends parfois le temps de lire).

          (et non dépliable au sein de la page)

          bin, si : suffit de cliquer sur le [-], non ?

          • [^] # Re: Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

            Posté par  . Évalué à 3 (+1/-0).

            bin, si : suffit de cliquer sur le [-], non ?

            Malheureusement non :
            Messages masqués

            Il faut cliquer sur le titre du message replié pour y accéder. Et du coup on quitte la lecture en cours.
            Je comprends qu'on replie les messages moinssés mais c'est quand même dommage qu'il faille carrément changer de page pour les lire. Je surfe aussi à -42 mais sachant que les nouveaux postent à 0 par défaut (sauf dans les forums), leurs messages sont masqués par défaut et difficilement accessibles pour tous les non-connectés.

          • [^] # Re: Sur la garantie de conformité d'un dispositif matériel numérique (même libre)

            Posté par  . Évalué à 2 (+1/-0).

            Le [-], c'est pour replier, c'est un [+] pour déplier. Dans tous les cas, ça n'apparaît que si on est connecté. C'est vrai que ça n'est pas très pratique pour le lecteur de passage, mais est-ce vraiment si gênant que ça ?

            Personnellement, je ne moinsse que très rarement aussi. Il faut vraiment que ça aille loin pour que j'en arrive à vouloir pénaliser les propos de quelqu'un.

  • # D'autres commentaires sur le Mooltipass dans une entrée de la section "Liens"

    Posté par  . Évalué à -6 (+1/-3). Dernière modification le 04/08/20 à 09:58.

    Il y a trois commentaires intéressants au sujet du Mooltipass, datés du 27 juillet 2020, sous une entrée de la section Liens du site Linuxfr.org.


    [ Gestion des étiquettes de la dépêche ]

    En m'inspirant des étiquettes de l'entrée précitée, j'ai ajouté les trois étiquettes mooltipass, mot_de_passe et gestionnaire_de_mots_de_passe à la présente dépêche.

    Note : je le précise notamment à titre incitatif (pour qu'un modérateur les valide), étant donné que quasiment aucune des étiquettes que je mets sur les contenus que je publie sur Linuxfr.org (particulièrement en journaux) n'apparaissent publiquement pour des tiers depuis quelques années (ça doit faire partie d'une politique de frustration systémique pour favoriser mon départ, mais je me réjouis déjà de voir qu'elle restent pour l'instant fonctionnelles…).

  • # Sauvegardes ?

    Posté par  . Évalué à 3 (+2/-0).

    Comment faites-vous pour sauvegarder la smartcard et /ou les mots de passe ? J'ai vu qu'il y a des exports fichier, mais ils restent très évasifs, ils parlent juste d'exports fichiers dans le cloud, à l'opposé de la sécurité hors-ligne tant vantée.
    Est-ce qu'on peut facilement imprimer un listing de mots de passes en clair pour avoir une copie physique en cas de pépin ?
    Est-ce que les exports fichiers sont chiffrés ? Si oui, y-a-t’il des détails d'implem là dessus ? Ca pourrait être une source de grosses faiblesses.
    Est-ce qu'on peut cloner facilement la smartcard pour en faire une copie de sauvegarde ?

Envoyer un commentaire

Suivre le flux des commentaires

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