Discussion :

[boboss123]

Bonjour,

Je recherche un document qui me permettrait de m'aiguiller sur quels algo de cryptages en 2019, il est préconisé d’utiliser et avec quelle taille de clef.

J'ai trouvé divers documents sur le web mais généralement non datés et non sourcés : donc difficile de s'y retrouver.

De ce que j'ai retenu :
- RSA : algo largement répandu, nécessitant l'utilisation d'une clef d'au moins 4096bits pour sécurisé
- DSA : ne pas utiliser car comporte une faille de sécurité. De plus, DSA ne peut pas être utilisé pour le chiffrement (uniquement pour de la signature).
- ECDSA : ne pas utiliser car il y a de grosse suspicion d"introduction de backdoors par la NSA dans certaines implémentations logicielles et hardwares.
- ED25519 : algo performant car basé sur les courbes elliptiques mais pose des problèmes de compatibilité du à sa jeunesse.
=> ces informations sont-elles bonnes et toujours d'actualité ?

Ce que je voudrai avoir, c'est une vue des différents types d'algo, de connaitre ceux qu'ils ne faut pas utiliser, et pour les autres, connaitre leurs avantages et inconvénients.

Merci d'avance,

[fredoche]

Pour mes audits de sécurités, les auditeurs se réfèrent à ce site : https://www.ssllabs.com

ils éditent un draft des best practices : https://github.com/ssllabs/research/...Best-Practices

Après pas de références aux backdoors NSA

[gangsoleil]

Bonjour,

C'est pour faire quoi ? Car selon que tu veuilles faire un logiciel de chat entre copains ou un logiciel professionnel ou bien militaire, les normes ne sont pas les mêmes.
C'est pour tourner où ? Car selon que tu aies un arduino ou un supercalculateur du top500, tu ne vas pas utiliser la même chose.
Quelles sont tes contraintes sécuritaires ? As-tu accès à un HSM, ou bien tout est logiciel ?

[boboss123]

Bonjour,

C'est pour faire quoi ? Car selon que tu veuilles faire un logiciel de chat entre copains ou un logiciel professionnel ou bien militaire, les normes ne sont pas les mêmes.

C'est pour le développement d'un équipement professionnel configurable à distance par Ethernet (et aussi par port console USB). L'équipement ne contiendra pas de données personnelles sensibles (à part logins et passwords).
Si la sécurisation est acceptable pour le militaire, c'est mieux : qui peut le plus, peu le moins.
=> quels sont les prérequis minimum ?
=> qu'est-ce qu’imposent les militaires ?

C'est pour tourner où ? Car selon que tu aies un arduino ou un supercalculateur du top500, tu ne vas pas utiliser la même chose.

Sur un µControtroleur 32bits.

Quelles sont tes contraintes sécuritaires ? As-tu accès à un HSM, ou bien tout est logiciel ?

Le µControleur n'intègre pas de fonctions de décryptage à la volée de la mémoire flash, mais il y a une fonction de protection en lecture (mais pas en écriture) contre les sondes type JTAG.
J'ai prévue d'utiliser une clef publique stockée dans le contrôleur pour valider la signature des fichiers de mise à jour pour éviter qu'un attaquant puisse injecter son propre firmware à distance. Pour le moment, je n'ai pas prévue de crypter les fichiers de mise à jour car ça ne me semble pas indispensable.
Pour le HTTPS, il y aura un certificat par défaut enregistré dans le firmware mais l’utilisateur pour injecter le sien (il sera enregistré dans une zone de flash interne du µControleur avec les logins et passwords).
=> Je compte imposer des certificats avec clef privées de 4096 bits (algo RSA).

ça vous semble suffisant ?

Remarque : pour les attaques sur site, ça me semble difficilement protégeable car l'attaquant pourra toujours écrire dans le µControleur via une sonde de programmation, il pourra donc modifier le comportement du produit et récupérer des données sensibles tel que logins/passwords et certificats/clefs HTTPS.

[gangsoleil]

Si la sécurisation est acceptable pour le militaire, c'est mieux : qui peut le plus, peu le moins.

Certes, qui peut le plus peut le moins, mais à quel prix ?

Lorsque tu te promènes dans la rue, tu n'as probablement pas de garde du corps, parce que tu ne penses pas que la dépense en vaille la peine. Pourtant, qui peut le plus peut le moins, donc tu vas en prendre un ?

La liste des choses que tu ne protèges pas au quotidien parce que le coût est trop élevé est assez énorme, et c'est la même chose en entreprise : des calculs avec des clés RSA de 4096 bits, sur un microcontrolleur 32 bits, est-ce que tu sais combien de temps ça prend ? As-tu fait un essai pour voir ? Est-ce que ce temps est acceptable ?

Si oui, alors c'est bien, mais j'ai un sérieux doute.

Si tu veux faire un essai, tu peux installer openssl sur ton micro-controlleur, et lancer la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

openssl speed rsa1024 rsa2048 rsa4096

[viper1094]

Un temps acceptable représenterait combien environ ?

[boboss123]

des calculs avec des clés RSA de 4096 bits, sur un microcontrolleur 32 bits, est-ce que tu sais combien de temps ça prend ? As-tu fait un essai pour voir ? Est-ce que ce temps est acceptable ?

Il faut que je fasse des tests pour voir mais c'est vrai qu'à priori 2048 bits devrait suffire pour être dans les normes des "bonnes pratiques à utiliser".
... après quand je vois les cahiers des charges des clients, ils demandent juste du HTTPS ou SSH (aucune autre précision)... ça fait un peu peur quand même... ok en faisant n'importe quoi, je réponds au besoin mais quand même...

[boboss123]

Pour mes audits de sécurités, les auditeurs se réfèrent à ce site : https://www.ssllabs.com

ils éditent un draft des best practices : https://github.com/ssllabs/research/...Best-Practices

Après pas de références aux backdoors NSA

Merci, je vais lire ça