Les derniers développements en matière de sécurité des appareils IoT

Asim : Pour l'instant, nous n'avons pas prévu de prendre en charge vos propres algorithmes cryptographiques. L'enclave sécurisée du SoC dispose d'une multitude d'algorithmes cryptographiques différents qui sont largement utilisés, mais pour l'instant, toute la prise en charge devra se faire par le biais d'un micrologiciel signé par NXP. Si vous pensez que des algorithmes spécifiques ne sont pas couverts par le super-ensemble de fonctions cryptographiques dont nous disposons, nous aimerions le savoir, afin de pouvoir les revoir à l'avenir. Mais pour l'instant, nous n'autorisons pas la mise en œuvre d'algorithmes personnalisés.

Asim : Vous pouvez utiliser l'enclave sécurisée EdgeLock pour crypter vos actifs SoC, qu'il s'agisse de vos modèles d'apprentissage automatique ou de votre propriété intellectuelle. Nous pouvons l'utiliser pour effectuer des mises à jour sécurisées spécifiques. Nous pouvons utiliser l'enclave EdgeLock pour protéger la fabrication. L'enclave sécurisée se prête donc à une multitude de fonctions de sécurité.

Asim : Intrinsèquement, l'enclave EdgeLock possède des API avec lesquelles n'importe quel OP-TEE, et en particulier l'OP-TEE lui-même, ou l'environnement de confiance pris en charge par Android, tel que Trusty, peut s'interfacer. Donc, une fois de plus, nous avons une prise en charge totale d'Android, et cela fonctionnera également de manière transparente avec notre enclave sécurisée.

Maciej : Oui. Aujourd'hui, nous proposons un plug-in pour Buildroot, de sorte que vous pouvez générer un SBOM en utilisant Vigiles à partir de n'importe quel Buildroot.

Maciej : Vigiles est proposé sous forme d'abonnement. Il n'y a donc pas d'attachement à un SBOM spécifique. Vous pouvez effectuer autant de scans que vous le souhaitez. Vous pouvez scanner autant de produits que vous le souhaitez. La licence est basée sur le nombre d'utilisateurs qui souhaitent utiliser cette solution.

Bob : C'est une bonne question. Et je pense qu'Asim en a parlé. Il existe différentes normes et réglementations pour chaque secteur, qui sont non seulement en place mais qui évoluent. C'est pourquoi, dans le cadre de nos SOM, nous examinons également les certifications SESIP de bas niveau et d'autres éléments de ce type. Ensuite, nous fournissons vraiment les éléments de base pour chaque client, afin d'identifier les éléments particuliers dont il a besoin.

Bob : C'est une bonne question. Si les clients ne l'autorisent pas, vous pouvez toujours créer des mises à jour de micrologiciels que vous pouvez télécharger directement sur les machines, sans support en nuage. Nous avons également des appareils cellulaires, dans la gamme cellulaire Digi XBee®, qui peuvent également effectuer des mises à jour hors bande de nos appareils. Mais vous pouvez certainement créer vos mises à jour de microprogrammes et permettre aux clients de les charger directement sur leurs machines.

Bob : Tous ces projets sont en cours et je m'attends à ce que, dans les 18 à 24 mois à venir, d'autres lois soient adoptées dans certains de ces États. Vous savez, cela varie en fonction des priorités, mais la situation évolue rapidement. C'est quelque chose qu'il faut surveiller tout au long du développement d'un produit intégré, parce qu'il sera différent au point de certification et au point de lancement qu'il ne l'était au départ.

Asim : Si je comprends bien la question, nous parlons d'un durcissement matériel configurable. En fait, nos produits sont soumis à un certain niveau de durcissement. Il est évident que nous avons différentes lignes de produits qui ont des exigences et des objectifs de sécurité différents. Ainsi, au fur et à mesure que nous avançons avec notre série i.MX 9, nous aurons à l'avenir des produits plus récents de la série i.MX 9 qui auront des caractéristiques et des renforcements plus avancés que ceux de notre génération actuelle. Mais, dès le départ, nous avons des capteurs et d'autres types de caractéristiques qui peuvent être configurés par le client pour assurer une meilleure protection, en fonction de son cas d'utilisation. Mais ce sont là quelques-unes des principales caractéristiques. J'espère avoir répondu à votre question. Si ce n'est pas le cas, je peux certainement vous fournir des conseils supplémentaires hors ligne.

Asim : Oui, nous avons un document API, et nous sommes également en train de créer un guide de l'utilisateur, mais fondamentalement, le document API donne des informations sur la façon d'interfacer avec les unités de messagerie qui seront l'entrée et la sortie de l'enclave sécurisée. Ces unités disposeront de fonctions spécifiques pour configurer des clés, des fonctions et une multitude de caractéristiques qui ne sont pas accessibles à l'utilisateur. Pour simplifier, l'API existe et nous fournirons certaines de ces informations. Ces informations sont disponibles dans le cadre de notre documentation d'habilitation.

Asim : Oui, pour i.MX 93, nous visons la norme FIPS 140-3. Nous sommes actuellement en cours de certification. Comme certains d'entre vous le savent peut-être, il s'agit d'un processus de certification assez long, c'est pourquoi nous le visons. Malheureusement, en raison du calendrier et des retards accumulés dans le processus de certification du NIST, ce processus traîne en longueur. Mais pour l'instant, nous visons à la fois le FIPS et le SESIP PSA de niveau 2, du côté du SoC. Donc, du point de vue du SoC, c'est ce que nous visons. Et puis, je pense que nous avons des solutions de TimeSys qui sont également conformes à la PSA. Je laisse à Bob le soin de voir s'il y a des projets dans ce domaine également.

Bob : Oui, je pense que c'est la même chose. Nous avons quelques projets en cours. Nous étudions les certifications PSA, et nous avons obtenu la certification FIPS 140-2 avec des clients spécifiques et nous avons exploité différentes choses pour nos SOM. Nous avons également étudié la norme FIPS 140-3. C'est donc quelque chose que nous verrons à l'avenir.