Un protocole peut-il être sécurisé par cryptage?

Question

C’est quelque chose que j’ai toujours voulu apprendre. Lorsque je conçois un système (logiciel ou matériel) dans lequel plusieurs composants communiquent entre eux, comment puis-je implémenter un cryptage simple ou d'autres fonctionnalités dans le protocole pour une sécurité de base?

De toute façon, je peux modifier le protocole, car j’ai un accès de bas niveau jusqu’à la série d’octets transmis / reçus.

Modifier: Je suis intéressé par la programmation intégrée, le cryptage simple par câble pour la sécurité des protocoles.

Answer 1

Vous dites "sécurité de base". mais cela ne veut pas dire grand chose. Quel est votre modèle de menace? Contre quel type d'attaque vous défendez-vous? Si vous transmettez des données de carte de crédit, vous devrez utiliser un cryptage robuste, tel que RSA. Mais je ne peux pas penser à un exemple qui nécessite "moins". protection. Si vous craignez que des pirates informatiques désassemblent votre code, tout est déjà fini - si c'est intéressant ou précieux, ils le pirateront. Sinon, vous avez perdu du temps à le mettre en œuvre.

Answer 2

La solution la plus simple, de loin, consiste simplement à utiliser une prise SSL au lieu d’une prise normale, à la manière HTTPS / FTPS.

Il n’ya aucune différence entre le protocole HTTP et HTTPS, la seule différence est qu’ils fonctionnent sur des ports différents (normalement 80 vs 443), l’un utilise un socket normal et l’autre, un socket crypté SSL.

Answer 3

N'implémentez pas le cryptage de base dans le sens de le concevoir à partir de la base. Il est TRÈS difficile d’implémenter correctement le cryptage.

Au lieu de cela, concentrez-vous sur l'utilisation du chiffrement disponible sur votre plate-forme ... quelle est votre plate-forme?

EDIT:

Consultez cette publication SO pour obtenir une liste du chiffrement. alternatives, dont certaines devraient fonctionner assez bien dans un environnement intégré (par exemple, CryptoPP et TomCrypt ).

Answer 4

OAuth peut être intéressant pour vous, afin de permettre le contrôle d'accès entre différentes API.

Si vous souhaitez uniquement un canal de données crypté, il est préférable de simplement superposer cette partie supérieure de votre protocole. passez par SSL ou SSH.

Answer 5

Si vous faites de la programmation intégrée, où est le problème de cryptage?

Tant que vous restez sur le même processeur, par exemple, le cryptage est inutile.

Si vous êtes préoccupé par les processeurs du périphérique, le cryptage peut s'avérer difficile, car un dsp ne dispose pas forcément de l'espace disponible pour un cryptage complexe.

Si vous voulez la rapidité, alors un algorithme symétrique est votre meilleur choix, et vous pouvez en faire beaucoup qui sont bons, comme Blowfish ou IDEA. Vous pouvez stocker une clé symétrique unique. Ainsi, s’ils peuvent démonter le périphérique, une seule clé sera découverte, mais chaque périphérique doit avoir sa propre clé.

Liez simplement chaque clé au numéro de série. Ainsi, si vous communiquez avec un serveur, transmettez le numéro de série au paquet et le serveur Web peut rechercher la clé symétrique correcte et le déchiffrer rapidement.

Si vous souhaitez effectuer un cryptage matériel rapide, j'ai développé pour ma thèse MSEE une famille de cryptage qui utilise le calcul d'ordre arbitraire, ce qui rendrait difficile la détermination de la clé car elle peut se trouver dans le circuit matériel à l'aide de microstrips, car pas de traitement, il serait relié directement devant l'antenne et tout ce qui passerait serait chiffré.

Answer 6

Il existe de nombreux éléments à prendre en compte lors de la conception d’un système sécurisé. Pour n'en citer que quelques-uns:

• Choix de schémas de chiffrement symétriques / asymétriques
• Algorithme de chiffrement (AES, Blowfish, DES)
• Choix des protocoles connus (par exemple, SSL)
• Gestion et distribution des clés
  • Une seule clé principale (si piraté, tout le système est compromis)
  • Clé par périphérique (la distribution de la clé peut être plus difficile)
  • Protection des principaux canaux de distribution
• Un pirate informatique potentiel aura-t-il facilement accès à un ou plusieurs appareils? Par exemple. un produit de consommation tel que X-box ou une boîte enfermée dans un central téléphonique. Il est plus difficile de se protéger contre le piratage si ce dernier a un accès physique.
• Facteurs humains - ingénierie sociale, etc.
• Un système est aussi sécurisé que son lien le plus faible.

Je vous suggère de lire le fiches de Bruce Schneier pour commencer.

Answer 7

OAuth est certainement une considération. En plus de cela, vous pouvez également envisager de WS-Security . En transmettant via un service Web, vous maintenez tout ce qui concerne la plate-forme et la langue. L'ajout de WS-Security signifie que le cryptage et le décryptage se trouvent sur la couche d'application (de bout en bout). Donc, tant que vous pensez que les messages sont en sécurité une fois qu'ils ont quitté l'expéditeur, vous savez qu'ils resteront en sécurité jusqu'à ce que le client reçoive le message (cela signifie qu'il ne sera pas déchiffré par le serveur et ALORS transmis au client. / destinataire, mais APRÈS que l’application réceptrice ait reçu le message).

Donc, fondamentalement, vous voudriez que OAuth sécurise / authentifie les différentes applications et que WS-Security sécurise les messages qui les transmettent.