Je te remercie pour cette présentation digne d'une plaquette marketing (hé!ho! ne te vexes pas, je suis taquin de nature!). Je connais Thalès globalement mais pas dans son organisation interne. Je pense que le sujet ici abordé concerne essentiellement le grand public et industriel; je ne pense pas que Thales utilise le résultat pour ses applications défense et armement. D'ailleurs, on s'autorise (dans les milieux autorisés) à se poser la question de savoir s'il n'y aurait pas une peu de tirage de couverture à soi: à la limite, je m'en fiche, bien au contraire surtout si celà pousse les autres fondeurs à metttre plus de sécurité dans les uC et uP (micro-contrôleurs / micro-processeurs).
Ne me fais pas dire ce que je n'ai pas dit: oui, Thales a une vrai expertise dans le domaine de la sécurité. Mais, à mon goût, je trouve qu'il ne partage pas suffisamment avec les communautés open-source et que celà ne se voit pas à mon niveau (plus développement/intégration que recherche) avec des micro-processeurs qui sont ridiculement peu performants par rapport à ceux qu'utilisent Thales.
C'est d'autant plus vrai que tu cites l'ensemble des entités et lorsqu'on connait le nombre d'employés; je ne trouve pas de référence à un mail de thalesgroup ni dans le code source que j'ai de freertos, ni dans le linux "rt" que j'ai sous la main. Pourtant, il y a des offres d'emploi/stage avec demande de maîtrise des ces os là...
En comparaison, il y a un certain temps, les NXP, Freescale, TI, Atmel(Microchip), Intel, Microsoft (entre autres) étaient de très mauvais contributeurs, je te laisse aller voir leurs contributions, c'est colossal et je les remercie!
Je propose un lien direct avec des conseils très concrets sur la sécurisation de uC/uP, en échange, le lien qui est proposé (merci quand même, je ne vais pas cracher dans la soupe!) vers des publications où il faut décliner toute son identité pour accéder à une information dont on ne saura pas la pertinence par rapport à ma recherche: hélas, je n'ai pas l'autorisation de fournir ces informations.
Pour être dans le concret, quand dans une installation, j'ai plus d'un millier (petite installation) de uC allant du 8 bits au 32 bits tous reliés par des bus spécifiques (pas le droit d'en dire plus sur les distances et sur les medium), et que je souhaite améliorer la sécurité globale du système alors que j'ai une contrainte économique très forte (Thales n'est pas présent dans mon segment): redondance de micro-processeurs, redondance d'appareils, synchronisations des redondants, mise en place de canaris à bon escient dans des uC à très faible empreinte, surveillance, tracking des modifications de configuration de périphériques internes/appareils hardware (donc autant surveillance interne qu'externe, utilisation de certaines préconisations de SIL4), utilisation d'un "serveur tiers" pour la validation de certaines demandes d'autorisation, etc. Je trouve plus d'information constructive dans des petites sociétés et chez les fondeurs ce qui fait que je serais tenté de me tourner vers eux d'abord avant d'aller voir Thales, ce qui n'est pas forcément raisonnable (celà dépend du projet)
La contrainte économique fait que j'aurais souhaité que les uP de génération actuelle aient plus de blocs hardware dédiés sécurité (on commence à avoir AES presqu'en standard, il y en a d'autres qu'on est obligé de faire en sw alors que le coût en hw serait négligeable): je suis sûr que si les pratiques de sécurisation étaient plus partagées depuis un moment, on en bénéficierait tous car les fondeurs intègrent les blocs que les client demandent.
Conclusion: je suis frustré qu'à mon niveau (et je pense représenter un certain nombre d'ingénieurs en systèmes embarqués dans des petites structures qui déploient des myriades de capteurs en réseau), on ne puisse pas bénéficier des miettes de recherches qui ont été amorties depuis bien longtemps... Et encore plus lorsque tu vois la NSA avec SELinux (sans l'utiliser, ça m'a aidé à trouver des pistes d'améliorations sur un système)
[^] # Re: Expertise de Thales
Posté par plr . En réponse au journal Thales rejoint la fondation RISC-V pour participer à la sécurisation des uProcesseurs open source. Évalué à 1.
Je te remercie pour cette présentation digne d'une plaquette marketing (hé!ho! ne te vexes pas, je suis taquin de nature!). Je connais Thalès globalement mais pas dans son organisation interne. Je pense que le sujet ici abordé concerne essentiellement le grand public et industriel; je ne pense pas que Thales utilise le résultat pour ses applications défense et armement. D'ailleurs, on s'autorise (dans les milieux autorisés) à se poser la question de savoir s'il n'y aurait pas une peu de tirage de couverture à soi: à la limite, je m'en fiche, bien au contraire surtout si celà pousse les autres fondeurs à metttre plus de sécurité dans les uC et uP (micro-contrôleurs / micro-processeurs).
Ne me fais pas dire ce que je n'ai pas dit: oui, Thales a une vrai expertise dans le domaine de la sécurité. Mais, à mon goût, je trouve qu'il ne partage pas suffisamment avec les communautés open-source et que celà ne se voit pas à mon niveau (plus développement/intégration que recherche) avec des micro-processeurs qui sont ridiculement peu performants par rapport à ceux qu'utilisent Thales.
C'est d'autant plus vrai que tu cites l'ensemble des entités et lorsqu'on connait le nombre d'employés; je ne trouve pas de référence à un mail de thalesgroup ni dans le code source que j'ai de freertos, ni dans le linux "rt" que j'ai sous la main. Pourtant, il y a des offres d'emploi/stage avec demande de maîtrise des ces os là...
En comparaison, il y a un certain temps, les NXP, Freescale, TI, Atmel(Microchip), Intel, Microsoft (entre autres) étaient de très mauvais contributeurs, je te laisse aller voir leurs contributions, c'est colossal et je les remercie!
Je propose un lien direct avec des conseils très concrets sur la sécurisation de uC/uP, en échange, le lien qui est proposé (merci quand même, je ne vais pas cracher dans la soupe!) vers des publications où il faut décliner toute son identité pour accéder à une information dont on ne saura pas la pertinence par rapport à ma recherche: hélas, je n'ai pas l'autorisation de fournir ces informations.
Pour être dans le concret, quand dans une installation, j'ai plus d'un millier (petite installation) de uC allant du 8 bits au 32 bits tous reliés par des bus spécifiques (pas le droit d'en dire plus sur les distances et sur les medium), et que je souhaite améliorer la sécurité globale du système alors que j'ai une contrainte économique très forte (Thales n'est pas présent dans mon segment): redondance de micro-processeurs, redondance d'appareils, synchronisations des redondants, mise en place de canaris à bon escient dans des uC à très faible empreinte, surveillance, tracking des modifications de configuration de périphériques internes/appareils hardware (donc autant surveillance interne qu'externe, utilisation de certaines préconisations de SIL4), utilisation d'un "serveur tiers" pour la validation de certaines demandes d'autorisation, etc. Je trouve plus d'information constructive dans des petites sociétés et chez les fondeurs ce qui fait que je serais tenté de me tourner vers eux d'abord avant d'aller voir Thales, ce qui n'est pas forcément raisonnable (celà dépend du projet)
La contrainte économique fait que j'aurais souhaité que les uP de génération actuelle aient plus de blocs hardware dédiés sécurité (on commence à avoir AES presqu'en standard, il y en a d'autres qu'on est obligé de faire en sw alors que le coût en hw serait négligeable): je suis sûr que si les pratiques de sécurisation étaient plus partagées depuis un moment, on en bénéficierait tous car les fondeurs intègrent les blocs que les client demandent.
Conclusion: je suis frustré qu'à mon niveau (et je pense représenter un certain nombre d'ingénieurs en systèmes embarqués dans des petites structures qui déploient des myriades de capteurs en réseau), on ne puisse pas bénéficier des miettes de recherches qui ont été amorties depuis bien longtemps... Et encore plus lorsque tu vois la NSA avec SELinux (sans l'utiliser, ça m'a aidé à trouver des pistes d'améliorations sur un système)