La plus petite implémentation AES pour les microcontrôleurs?


38

Quelqu'un peut-il recommander une petite implémentation gratuite d'AES-128 Rijndael pour les microcontrôleurs. Idéalement, pour le PIC18, une implémentation générale en C serait utile.

La compilation de l'implémentation axTLS pour PIC18 et le chiffrement / déchiffrement d'un bloc nécessitent 6 Ko de ROM et 750 Mo de RAM.

La compilation de rijndael-alg-fst.c pour PIC18 et le chiffrement / déchiffrement d'un bloc nécessitent une mémoire vive de 28 Ko et une mémoire vive de 0,5 Ko.

La compilation de l’ AES 8 bits de Brian Gladman pour PIC18 et le chiffrement / déchiffrement d’un bloc nécessitent 19 Ko de ROM et 190 octets de RAM.

Existe-t-il des variantes optimisées spécifiques au PIC?

(exigences de RAM mises à jour pour la version axTLS)


1
Est-ce pour le chargeur de démarrage?
Daniel Grillo

Non, c'est pour une application réseau
Toby Jaffey

Microchip a une implémentation pour dsPIC et PIC 24 qui a une taille de code de 3 018 octets, mais elle n’avait que le cryptage, pas de décryptage. En supposant que cela ne coupe pas pour vous cependant.
Kellenjb

@ Kellenjb Intéressant, mais je cherche quelque chose de petit pour micros 8 bits
Toby Jaffey

1
@mikeselectricstuff Oui, il faut que ce soit AES. J'essaie d'interopérer avec un système existant utilisant AES-128. Je suis intéressé par toute petite implémentation AES, mais je cible actuellement PIC18. J'utilise le compilateur picc18 HiTech Pro.
Toby Jaffey

Réponses:


19

Je me demande comment vous avez pu utiliser 7,5 Ko de RAM avec axTLS. En regardant le code, tout le contexte est stocké dans cette structure:

typedef struct aes_key_st 
{
    uint16_t rounds;
    uint16_t key_size;
    uint32_t ks[(AES_MAXROUNDS+1)*8];
    uint8_t iv[AES_IV_SIZE];
} AES_CTX;

La taille de cette structure est 2 + 2 + 4 * 15 * 8 + 16 = 504. Je ne vois aucune variable globale dans aes.c, les variables automatiques étant toutes petites, l'utilisation de la pile est également raisonnable. Alors, où va 7,5 ko? Peut-être essayez-vous d'utiliser toute la bibliothèque au lieu d'en extraire l'implémentation AES?

Quoi qu'il en soit, cette mise en œuvre semble assez simple, je préfère m'en tenir à ce code et essayer de l'optimiser. Je sais que cela peut être délicat, mais l’apprentissage des détails de l’AES peut au moins vous aider à estimer l’utilisation minimale absolue de la mémoire RAM.

Mise à jour: je viens d’essayer de compiler cette bibliothèque sur Linux IA-32 et d’écrire un simple test de cryptage CBC AES-128. Vous obtenez les résultats suivants (le premier chiffre correspond à la longueur de la section hexadécimale):

 22 .data         00000028  0804a010  0804a010  00001010  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 23 .bss          00000294  0804a040  0804a040  00001038  2**5
                  ALLOC

C'est juste 660 octets de .bss (j'ai déclaré AES_CTX comme une variable globale). La plupart des fichiers .data sont occupés par IV et par clé. Je n'inclue pas .text ici, car vous obtiendrez un résultat totalement différent sur PIC (les sections de données devraient avoir presque la même taille sur les deux architectures).


J'ai mal lu par un facteur de 10 sur la version axTLS. Tu as raison. Mais je suis toujours intéressé par des versions plus efficaces d'AES ...
Toby Jaffey

5
Efficace en termes de taille ou de vitesse? Quelles sont les contraintes, en réalité? Gardez à l'esprit que les petites bibliothèques seront probablement plus lentes - si vous examinez le code source des plus grandes bibliothèques (en termes de section de code), la plus grande partie de la saturation est due à des tableaux constants pré-calculés.
Code Painters

1
En termes d'encombrement de la RAM et de la ROM. La vitesse n'est pas un problème, mais je cherche à intégrer beaucoup de fonctionnalités dans un petit appareil.
Toby Jaffey le

14

Je sais que cette question est un peu ancienne, mais je viens tout juste de faire des recherches moi-même, alors que je m’applique à AES128 sur un PIC16 et un 8051, et j’étais donc curieux de connaître cette question.

J'ai utilisé quelque chose comme ceci: http://cs.ucsb.edu/~koc/cs178/projects/JT/aes.c et mon utilisation de RAM est de quelques centaines d'octets et la taille binaire est inférieure à 3 Ko de ROM.

Mon meilleur conseil est de lire sur la page Wikipedia http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation et de comprendre les différents modes, par exemple comment AES en mode OFB utilise le mode ECB comme bloc de construction de base. De plus, le XOR (en mode OFB) en fait une opération symétrique. Crypter / décrypter est donc la même fonction, ce qui permet également de gagner de la place.

Lorsque j'ai compris le fonctionnement réel d'AES, je pouvais l'implémenter en C, puis le tester par rapport à la spécification NIST ** (beaucoup de code trouvé en ligne est défectueux) et ne mettre en œuvre que ce dont j'avais absolument besoin.

J'ai pu adapter AES128 sur un 8051 avec un autre micrologiciel RF en effectuant cette personnalisation et cette optimisation. L'utilisation de la mémoire RAM (pour l'ensemble du système) est passée d'environ 2,5 Ko à un peu moins de 2 Ko, ce qui signifie que nous n'avons pas eu besoin de passer à une 8051 avec SRAM de 4 Ko, mais que nous pouvions continuer à utiliser la version moins coûteuse de SRAM de 2 Ko.

** Les vecteurs de test figurent à l’Annexe F à l’ adresse suivante : http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf

MODIFIER:

Enfin obtenu le code sur Github: https://github.com/kokke/tiny-AES-c

J'ai optimisé un peu pour la taille. Sortie de taille GCC lors de la compilation pour ARM:

$ arm-none-eabi-gcc -O2 -c aes.c -o aes.o
$ size aes.o
   text    data     bss     dec     hex filename
   1024       0     204    1228     4cc aes.o

Ainsi, l’utilisation des ressources est désormais de 1 Ko, soit 204 octets de RAM.

Je ne me souviens pas comment construire pour le PIC, mais si le AVR Atmel Mega16 à 8 bits ressemble à un PIC, l'utilisation des ressources est la suivante:

$ avr-gcc -Wall -Wextra -mmcu=atmega16 -O2 -c aes.c -o aes.o
$ avr-size aes.o
   text    data     bss     dec     hex filename
   1553       0     198    1751     6d7 aes.o

Donc 1,5K code et 198bytes de RAM.


Je me demande comment une implémentation que j'avais réalisée en 2001 se classerait Il ne génère pas les S-box; ils sont statiques.
Kaz

6

J'ai récemment pris l'implémentation d'axTLS et j'ai travaillé à la réduire autant que possible. Vous pouvez facilement générer vous-même les boîtes S et économiser quelques centaines d’octets.

static uint8_t aes_sbox[256];   /** AES S-box  */
static uint8_t aes_isbox[256];  /** AES iS-box */
void AES_generateSBox(void)
{
    uint32_t t[256], i;
    uint32_t x;
    for (i = 0, x = 1; i < 256; i ++)
    {
        t[i] = x;
        x ^= (x << 1) ^ ((x >> 7) * 0x11B);
    }

    aes_sbox[0] = 0x63;
    for (i = 0; i < 255; i ++)
    {
        x = t[255 - i];
        x |= x << 8;
        x ^= (x >> 4) ^ (x >> 5) ^ (x >> 6) ^ (x >> 7);
        aes_sbox[t[i]] = (x ^ 0x63) & 0xFF;
    }
    for (i = 0; i < 256;i++)
    {
         aes_isbox[aes_sbox[i]]=i;
    }
}

Vous pouvez obtenir le code complet à l’ adresse suivante : http://ccodeblog.wordpress.com/2012/05/25/aes-implementation-in-300-lines-of-code-


Tu connais tes affaires, Andrew. Upvote. : D
Alex

3

Je réalise une implémentation en C, uniquement AES-128, appelée aes-min , avec licence MIT. Il cible les petits microprocesseurs (par exemple 8 bits) avec peu de RAM / ROM.

Il dispose d'un calcul de planification de clé à la volée facultatif pour réduire les besoins en mémoire (évitant ainsi la nécessité d'une planification de clé entièrement étendue dans la RAM).


1

Vous pouvez trouver cette implémentation intéressante. C’est à partir d’un crypto-libary AVR open source.

Vous trouverez des informations générales (obsolètes) et des statistiques sur la taille du code et les performances ici .

AES:

Informations AES

Je n'ai joué qu'avec la source SHA-1 de cette librairie, donc je ne peux pas commenter sur AES.



0

Le plus petit AES128 que j'ai écrit pour la série PIC peut fonctionner avec 900 instructions et 42 octets de RAM. Je l'utilise moi-même sur la série PIC12 mais le PIC10F206 est également possible :-).

Je ne peux pas divulguer le code car il provient de mon entreprise mais je l’ai écrit dans asm pour la série PIC10-12-16. Le cryptage prend 444 octets de code, y compris une table de consultation de 256 octets. Ce code incluait également la fonction de chargement de clé, soit environ 25 octets.

Je vous conseillerais de vérifier le papier AES et de le mettre en œuvre vous-même! La plupart des implémentations sont très mauvaises et utilisent beaucoup de ressources RAM et ROM.

J'ai également implémenté AES128 pour dsPIC et PIC24 et utilise environ 70% moins d'espace de code par rapport à la lib de microchip et mon code est également un peu plus rapide. Numéros d'implémentation de dsPIC et PIC24:

"Le cryptage prend environ 2995 cycles. 79.10uS @ 40 MIPS, 197.75uS @ 16 MIPS"

"DecKeySetup prend environ 567 cycles. 14.20uS @ 40 MIPS, 35.43uS @ 16 MIPS"

"Le déchiffrement prend environ 3886 cycles. 97.15uS @ 40 MIPS, 242.88uS @ 16 MIPS"

"La taille totale du code est de 1050 mots, y compris les tables."

La beauté du noyau PIC24 réside dans le fait que certaines instructions sont en 32 bits, ce qui simplifie grandement la tâche pour la construction d’une petite implémentation AES128. PIC32 ou autres processeurs 32 bits.

AES est très simple à mettre en œuvre que la plupart des gens n'essayent même pas!

Regardez le lien: http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf


Est-ce open source? Pouvez-vous poster le code?
Toby Jaffey

2
@Paul - Bienvenue sur Electrical Engingeering! Votre réponse est intéressante et encourageante, mais elle n’est pas vraiment utile sans plus de détails. 900 instructions pourraient probablement tenir dans un bloc de code! Veuillez cliquer sur le lien "modifier" situé sous la réponse pour l’améliorer.
Kevin Vermeer

@PaulHolland bonne nouvelle, où est le code?
Frank

2
@Paul - Vous obtiendrez une pile de votes positifs au lieu des votes négatifs si vous expliquiez comment vous l'avez écrit et avez posté le code! Si vous ne pouvez pas publier le code pour des raisons de licence, expliquez au moins comment vous l'avez écrit et comment Joby pourrait suivre votre travail.
Kevin Vermeer le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.