Pour avoir bosser pour le labo de canal+ sur le sujet, je peux dire qu'il y a un monde entre une carte à puce, et un microcontrôleur classique. Bien sur, je ne dirais pas que c'est impossible, mais conceptuellement être capable de sortir un secret d'une carte à puce particulière (et non un secret identique recopié sur 20 puces), c'est vraiment très compliqué, avoir un FIB, un LSM, un AFM, un microscope électronique, n'aide pas vraiment.
Pour faire ça, il faut connaitre parfaitement le modèle de la puce elle-même, voir si elle a une faiblesse. Ensuite, il vaut mieux avoir une autre clef avec le logiciel utilisé dans la cible, pour voir si le soft à une faiblesse. Et ensuite, s'attaquer à la clef cible en question, sachant qu'il y a une haute proba de destruction.
Dans un microcontrôleur, il suffit souvent d'utiliser le JTAG.
La sécurité est forcément par la sécurité car chaque mesure est imparfaite. L'exemple du shield est intéressant. Ils ont fait une version avec un registre il fallait lire et écrire dedans pour voir si un fil était coupé. Mais cela laissait quelques milliers de cycle à l'allumage sans protection. Ensuite, ils ont fait des "versions analogiques" qui mesuraient la résistance du shield pour détecter un by-pass. L'emplacement des détecteurs de laser n'est pas connu, cela oblige l'attaquant a cartographier la puce, pour ne pas taper dedans. Si une sécurité repose sur un nombre secret, si il est connu, cela ne marche plus (clef de chiffrage de la mémoire, ou autre), etc…
Le comportement du CMOS est connu, c'est presque une boite blanche, le seul moyen de planquer quelques choses dedans, c'est de faire une boite et de faire grossir la meule de foin.
Oui si tu passes par budget insight qui gère les modifications des banques, sinon c'est à toi de gérer chaque changement d'interface. Et budget insight vend son truc pour des applications bancaires, pas pour une PME qui veut automatiser sa relation avec sa banque.
Pour autant, d’une part Gnuk ne laisse pas les clefs dénuées de toute protection comme on vient de le voir, et d’autre part la « résistance aux attaques physiques » (tamper resistance) n’est ni l’apanage des cartes à puce, ni absolue. Carte à puce ou pas, il est toujours prudent de considérer qu’un adversaire motivé et équipé pourra extraire des données du jeton, si besoin en dépiautant la puce et en allant directement lire la valeur des bits au microscope.
Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret, car il est trop facile de détruire la puce pendant le processus. Ce n'est pas le cas d'un chip normal.
Une carte à puce dispose d'un "shield", une grille que l'on doit "dériver" pour accéder au bus de la FLASH. Une protection de l'alimentation et des pin d'entré pour éviter les glitchs. Ils disposent aussi de capteur de laser qui détruit la mémoire, pour éviter l'injection de faute. Les mémoires internes sont cryptés. Des secrets peuvent être en dur, (genre fonction de dérivation de clef qui ajoute un grand nombre). Si vous voulez ce nombre pour avoir l'algo de dérivation de clef complet, il faut faire du reverse hardware ou avoir des bons contacts dans le service de sécurité du fabricants.
Une fois, j'avais entendu parler d'un "hash hardware" sur un SoC, mais c'était simplement un bloc AES, or AES est connu pour être une mauvaise fonction de hachage. Le truc a été cassé.
J'ai connu une histoire d'une personne étant parti au japon qui n'a pas réussi à dormir pendant 3 jours. Alors pourquoi l'inverse, pour dormir, ne pourrait pas exister ?
Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
Non, la banquière était la responsable entreprise.
Dans le cas de librapay, ou il y a transfert d'argent, il faut être certifier PCI-DSS pour conserver l'argent de personne pour ensuite, le redistribuer. Je connais Lemonway dans le lot.
En général une banque ne propose pas d'API. Quand j'ai parler de ça à une banquière, elle m'a dit : "oui vous avez une interface web pour envoyer votre fichier de paiement chaque mois…"
UEFI n'est pas utilisé sur ARM, à ma connaissance, et n'est pas du tout rendu obligatoire par un standard quelconque. La norme PCI est un bon exemple, mais cela n'est jamais utilisé dans un SoC. le device tree ne répond pas au problème. Est-ce que l'on imagine un device-tree pour chaque combinaison de hardware pour un PC ?
Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner.
Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.
Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".
Si il pouvait aussi spécifier le boot loader… Linux a seulement besoin de l'horloge, d'une liaisons série, et de DRAM fonctionnelle (certain plateforme nécessite d'écrire une configuration dans le contrôleur DRAM qui utilise par défaut des valeurs conservatrices très lente), à cela il faut rajouter une table standard pour identifier les périphériques sur le bus (comme pour le PCI) et c'est bon (il faut juste une adresse mémoire + un numéro d'identification unique).
On peut rajouter à tout ça un boot USB et/ou SD pour démarrer une première fois, et l'on a tout ce qu'il faut non ?
Je ne sais pas si cela a changé, mais un des énormes problèmes de ARM est l'absence d'un équivalent au bios, qui permet la détection des périphériques. Cela rend totalement impossible d'avoir un binaire universel ARM pour Linux, par exemple.
Le deep learning, qui a relancé la mode de l'IA, c'est la détermination automatique des "features" avec l'aide de beaucoup d'exemples (big data) ou d'un simulateur (cf alphazero).
En tout cas, vous êtes dans le cas idéal pour utiliser les CPU à fond : localité d'accès + pas d'IO + vectorisation.
Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.
[^] # Re: euh...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 3.
Pour avoir bosser pour le labo de canal+ sur le sujet, je peux dire qu'il y a un monde entre une carte à puce, et un microcontrôleur classique. Bien sur, je ne dirais pas que c'est impossible, mais conceptuellement être capable de sortir un secret d'une carte à puce particulière (et non un secret identique recopié sur 20 puces), c'est vraiment très compliqué, avoir un FIB, un LSM, un AFM, un microscope électronique, n'aide pas vraiment.
Pour faire ça, il faut connaitre parfaitement le modèle de la puce elle-même, voir si elle a une faiblesse. Ensuite, il vaut mieux avoir une autre clef avec le logiciel utilisé dans la cible, pour voir si le soft à une faiblesse. Et ensuite, s'attaquer à la clef cible en question, sachant qu'il y a une haute proba de destruction.
Dans un microcontrôleur, il suffit souvent d'utiliser le JTAG.
La sécurité est forcément par la sécurité car chaque mesure est imparfaite. L'exemple du shield est intéressant. Ils ont fait une version avec un registre il fallait lire et écrire dedans pour voir si un fil était coupé. Mais cela laissait quelques milliers de cycle à l'allumage sans protection. Ensuite, ils ont fait des "versions analogiques" qui mesuraient la résistance du shield pour détecter un by-pass. L'emplacement des détecteurs de laser n'est pas connu, cela oblige l'attaquant a cartographier la puce, pour ne pas taper dedans. Si une sécurité repose sur un nombre secret, si il est connu, cela ne marche plus (clef de chiffrage de la mémoire, ou autre), etc…
Le comportement du CMOS est connu, c'est presque une boite blanche, le seul moyen de planquer quelques choses dedans, c'est de faire une boite et de faire grossir la meule de foin.
"La première sécurité est la liberté"
[^] # Re: Sécurité ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Falkon 3 le nouveau navigateur pour KDE. Évalué à 8.
Pourquoi avoir mis le même nom ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 2. Dernière modification le 13 juillet 2018 à 11:35.
Bien sûr. Mais qui en utilise encore ?
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 4.
Oui si tu passes par budget insight qui gère les modifications des banques, sinon c'est à toi de gérer chaque changement d'interface. Et budget insight vend son truc pour des applications bancaires, pas pour une PME qui veut automatiser sa relation avec sa banque.
"La première sécurité est la liberté"
# euh...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 5.
Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret, car il est trop facile de détruire la puce pendant le processus. Ce n'est pas le cas d'un chip normal.
Une carte à puce dispose d'un "shield", une grille que l'on doit "dériver" pour accéder au bus de la FLASH. Une protection de l'alimentation et des pin d'entré pour éviter les glitchs. Ils disposent aussi de capteur de laser qui détruit la mémoire, pour éviter l'injection de faute. Les mémoires internes sont cryptés. Des secrets peuvent être en dur, (genre fonction de dérivation de clef qui ajoute un grand nombre). Si vous voulez ce nombre pour avoir l'algo de dérivation de clef complet, il faut faire du reverse hardware ou avoir des bons contacts dans le service de sécurité du fabricants.
"La première sécurité est la liberté"
[^] # Re: Gniibe préfère aussi le hard générique et documenté
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 3. Dernière modification le 13 juillet 2018 à 09:47.
Une fois, j'avais entendu parler d'un "hash hardware" sur un SoC, mais c'était simplement un bloc AES, or AES est connu pour être une mauvaise fonction de hachage. Le truc a été cassé.
"La première sécurité est la liberté"
[^] # Re: fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 3.
J'ai pas dit mal, j'ai dis pas du tout, au point de se faire hospitaliser.
"La première sécurité est la liberté"
[^] # Re: fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 2.
Pourquoi ?
J'ai connu une histoire d'une personne étant parti au japon qui n'a pas réussi à dormir pendant 3 jours. Alors pourquoi l'inverse, pour dormir, ne pourrait pas exister ?
"La première sécurité est la liberté"
# fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 10.
As tu tenter le voyage pour te placer dans un fuseau horaire qui te plait plus ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Je pense à un système beaucoup plus petit. La table dont je parle pourrait faire pas plus de qq ko. Il faut juste que l'adresse soit fixe.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3. Dernière modification le 12 juillet 2018 à 08:52.
pour une utilisation perso sans doute, pro, je doute beaucoup plus.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 5.
Non, la banquière était la responsable entreprise.
Dans le cas de librapay, ou il y a transfert d'argent, il faut être certifier PCI-DSS pour conserver l'argent de personne pour ensuite, le redistribuer. Je connais Lemonway dans le lot.
"La première sécurité est la liberté"
[^] # Re: Stripe ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
lemonway avait (a?) un payback de 30€, ce qui le rend impossible à utiliser pour des petits montants.
Pour Strip, je vois 1.4%+0.25€ de frais CB contre 1.8%+.18€ de frais pour Mangopay, on est pas au double, ou alors, j'ai oublié un truc ?
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 7.
En général une banque ne propose pas d'API. Quand j'ai parler de ça à une banquière, elle m'a dit : "oui vous avez une interface web pour envoyer votre fichier de paiement chaque mois…"
"La première sécurité est la liberté"
[^] # Re: Stripe ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
pas mal dans quel sens ? Il gère des comptes chez eux ?
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
En fait, c'est l'inverse. Car ils rendent la gestion du logiciel, infiniment plus complexe. Et l'ISA, c'est du logiciel.
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
UEFI n'est pas utilisé sur ARM, à ma connaissance, et n'est pas du tout rendu obligatoire par un standard quelconque. La norme PCI est un bon exemple, mais cela n'est jamais utilisé dans un SoC. le device tree ne répond pas au problème. Est-ce que l'on imagine un device-tree pour chaque combinaison de hardware pour un PC ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Le device tree ne change absolument rien. Le device tree décrit spécifiquement le contenu d'un SoC pour pouvoir fonctionner.
Il est totalement impossible de "découvrir" les périphériques et aller chercher le bon driver.
Pour le 2), non cela serait simplement une adresse mémoire fixe pour tous les ARM, avec la liste des périphériques (genre numéro unique, et adresse mémoire). Sur un soc, cela peut être de la "mémoire compilé".
"La première sécurité est la liberté"
[^] # Re: Point de vue pragmatique mais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 6.
Si il pouvait aussi spécifier le boot loader… Linux a seulement besoin de l'horloge, d'une liaisons série, et de DRAM fonctionnelle (certain plateforme nécessite d'écrire une configuration dans le contrôleur DRAM qui utilise par défaut des valeurs conservatrices très lente), à cela il faut rajouter une table standard pour identifier les périphériques sur le bus (comme pour le PCI) et c'est bon (il faut juste une adresse mémoire + un numéro d'identification unique).
On peut rajouter à tout ça un boot USB et/ou SD pour démarrer une première fois, et l'on a tout ce qu'il faut non ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 10. Dernière modification le 11 juillet 2018 à 11:01.
Je ne sais pas si cela a changé, mais un des énormes problèmes de ARM est l'absence d'un équivalent au bios, qui permet la détection des périphériques. Cela rend totalement impossible d'avoir un binaire universel ARM pour Linux, par exemple.
"La première sécurité est la liberté"
[^] # Re: Heuristique
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage pour vous, un logiciel d'intelligence artificielle, c'est quoi ?. Évalué à 5.
Le deep learning, qui a relancé la mode de l'IA, c'est la détermination automatique des "features" avec l'aide de beaucoup d'exemples (big data) ou d'un simulateur (cf alphazero).
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 4.
En tout cas, vous êtes dans le cas idéal pour utiliser les CPU à fond : localité d'accès + pas d'IO + vectorisation.
Et coté chaleur, vous avez fait quelques choses ? Les derniers cpu d'intel parte du principe qu'ils doivent ralentir au delà d'une certaine température, ce qui est forcément le cas avec un cas d'usage aussi intense.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 3.
Il y a aussi beaucoup de simulateur qui crache beaucoup de log, ou qui font des checkpoints pour reprendre leur travaux en cas de crash.
"La première sécurité est la liberté"
[^] # Re: HT et performances...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 3.
Peu d'IO alors ?
"La première sécurité est la liberté"