La couche d’application et la bibliothèque crypto WMLScript

Les spécifications de Forum WAP définissent la bibliothèque WMLScript Crypto [WMLSC] pour un environnement WAP plus sécurisé. Dans cette bibliothèque, deux fonctions sont disponibles :

EncryptText et SignText. La première permet de signer une portion de texte. Cette opération peut

être faite via l’utilisation du module WIM et permet d’authentifier le client auprès du serveur final. La deuxième nous permet de chiffrer les données afin de s’assurer de leur intégrité.

4.2.1.1 La fonction EncryptText

WapEnvelopedData est un format de chiffrement de données. Il est associé à la fonction encrypt()

et il contient les informations indispensables au déchiffrement de données : les algorithmes utilisés, le document chiffré, les informations d’identification de la clé publique utilisée pour chiffrer la clé de session et le cryptogramme contenant la clé de session chiffrée sous cette clé publique.

Nous utilisons l’algorithme RSA pour la distribution de clé et l’algorithme 3-DES pour le chiffrement symétrique.

4.2.1.2 La fonction SignText

4.2.1.2.1 Format de données signées - SignedContent

Les normes du Forum WAP définissent un format propriétaire, noté SignedContent, pour la transmission de données signées en provenance ou à destination d’un terminal WAP. A la différence des normes de l’IETF (Internet), tel que PKCS#770 [PKCS7], ce format est très léger et facile à implémenter.

Les données contenues dans ce nouveau format sont de quatre sortes : • Une signature

• Des informations sur les données signées (le message est optionnellement inclus)

• Des informations sur le signataire (valeur nulle, condensât de la clé publique ou du certificat) • Des attributs (heure GMT ou valeur aléatoire).

La signature ainsi obtenue ne porte que sur le message à signer. Les informations complémentaires du format SignedContent (informations sur le signataire, attributs) ne sont pas protégées.

Il est avantageux d’inclure le message initial dans les données signées car alors, le format

SignedContent suffit pour transmettre un message et la signature associée.

Un exemple du format SignedContent est donné ci-dessous :

Struct { Uint8 version; // 0x01h Signature signature; // stocke la signature SignerInfo signer_info<0..2^16-1>; // stocke les informations relatives au signataire

ContentInfo content_info;

// stocke les informations relatives au contenu qui est signé AuthenticatedAttribute authenticated_attributes<0..255>;

// stocke des informations supplémentaires concernant le signataire } SignedContent;

Nous citons ici que nous avons également le champ algorithm (sur un octet) qui contient le type de l’algorithme utilisé pour la signature. Pour l’instant, la norme en définit 3. Dans l’exemple ci- dessus, il a pour valeur 0x01h, c’est-à-dire rsa_sha_pkcs1. Ensuite, nous retrouvons la signature sous forme d’opaque vecteur, pour laquelle la taille est indiquée sur 2 octets. C’est donc une signature de 128 bits. La fabrication de la signature se fait suivant le standard PKCS#1 [PKCS1] et elle se décompose en 3 étapes.

La première étape consiste à calculer le condensât du message (le texte que nous voulons signer) en utilisant l’algorithme SHA-1 [SHA1]. Le condensât obtenu a une taille de 20 octets. La seconde étape consiste à intégrer ce condensât dans une structure DER [ASN-DER] décrivant une structure XDR DigestInfo. Le tout forme alors une chaîne de 35 octets. Cette chaîne est ensuite chiffrée avec la clé privée de l’utilisateur. Cela donne la signature que nous intégrons dans le champ signature.

4.2.1.2.2 Détail de la fonction SignText

Cette fonction est conforme au document [WMLSC] :

signedString = Crypto.SignText(stringToSign, options, keyIdType, keyed)

Elle permet à l’utilisateur de signer un message. L’utilisateur doit entrer le code confidentiel pour activer la clé de signature de la carte WIM. Ce code doit être saisi pour chaque signature générée. Un message au format base-64 est alors généré, il contient un message SignedContent. Les propriétés du message SignedContent généré sont:

Signature Algorithms RSA/SHA selon PKCS #1 v1.5

RSA/SHA selon PKCS #1 v1.5, compatible PKCS #7 Signer Info Types Implicit (the signer is implied by the content)

The SHA-1 hash of the public key X509, WTLS and URL certificates are not supported.

Content Types Text

Content Present TRUE FALSE Authenticates Attributes Signer nonce

4.2.1.3 La fonction Verify

La fonction Verify n’est pas spécifiée par le Forum WAP. Dans le cadre du projet SWAP, nous avons choisi l’interface :

authenticatedString = Crypto.verify(signedString)

Elle permet à l’utilisateur de vérifier l’intégrité d’un message signé, d’afficher l’identité du signataire, et suivant le type de contenu :

• d’afficher le texte signé à l’écran,

• de sauvegarder les données signées dans un fichier (cas d’un exécutable).

Les ressources WIM ne sont pas utilisées par cette fonction parce que la vérification de signature est faite dans le mobile. Les propriétés du message SignedContent sont illustrées dans le tableau suivant.

Signature Algorithms RSA/SHA selon PKCS #1 v1.5

RSA/SHA selon PKCS #1 v1.5, compatible PKCS #7 Signer Info Types The SHA-1 hash of the public key

Content Types Text (il s’agit d’un message signé à afficher)

Data (il s’agit de données à sauvegarder dans un fichier) Content Present TRUE

Les données sont limitées à 64 Ko. Authenticates Attributes 1) Signer nonce : valeur aléatoire.

2) GMT Time : temps universel. Tableau 4.2. Les propriétés des messages Verify.

Dans ce cadre, les applications développées (mail signé, téléchargement des fichiers signés, etc.) manipulent différents formats de signature. Ces formats sont cités dans l’annexe B.

4.2.1.4 Le passage de SignedContent à PKCS#7

Rappelons que la signature d’un message au format PKCS#7 porte sur : le message à signer, un attribut (heure GMT ou valeur aléatoire) et sur des valeurs fixes, alors que dans le cas de

SignedContent, la signature ne porte que sur le message à signer.

Un message de type SignedContent peut se convertir à tout moment en un message de type PKCS#7 et réciproquement. Par contre, la signature n’est pas identique d’un format à l’autre puisque les données signées diffèrent.

Pour permettre cette conversion, il est nécessaire d’enrichir la fonction SignedContent et d’introduire un nouveau schéma de signature côté mobile. Ce nouveau mode consiste à signer, pour le message de type SignedContent, les données qui seraient signées dans un message de type PKCS#7. Le reste du traitement est inchangé.

La norme WMLScript Crypto Librairie [WMLSC] définit des "formulaires" pour effectuer le passage d’un format SignedContent à un format PKCS#7. L’utilisation de ces formulaires se fait en réutilisant les champs d’un message SignedContent et en les intégrant dans une représentation DER d’une structure PKCS#7. La norme définit deux formulaires possibles en fonction du type

AuthenticatedAttribute présenté dans le SignedContent. Elle définit aussi quatre nouveaux Object Identifier pour désigner d’objets du SignedContent en XDR [XDR] et leur codage DER. Ces

Attribute OID OID en binaire

ContentType pkcs9-3 2A 86 48 86 F7 0D 01 09 03 MessageDigest pkcs9-4 2A 86 48 86 F7 0D 01 09 04 SigningTime pkcs9-5 2A 86 48 86 F7 0D 01 09 05 SignerNonce pkcs9-25-3 2A 86 48 86 F7 0D 01 09 19 03

Figure 4.1. La conversion entre SignedContent et PKCS#7 Les formulaires changent selon le type d’attribut :

• dans le cas où l’attribute_type serait un temps gmt_utc_time, nous avons :

31 5D Set (93 octets)

. 30 18 Sequence (24 octets)

. . 06 09 2A 86 48 86 F7 0D 01 09 03 – Object Identifier: contentType . . 31 0B Set (11 octets)

. . . 06 09 2A 86 48 86 F7 0D 01 07 01 – Object identifier: pkcs7-data . 30 1C Sequence (28 octets)

. . 06 09 2A 86 48 86 F7 0D 01 09 05 – Object Identifier: signingTime . . 31 0F Set (16 octets)

. . . 17 OD xx xx xx xx xx xx xx xx xx xx xx xx xx – UTCTime . 30 23 Sequence (35 octets)

. . 06 09 2A 86 48 86 F7 0D 01 09 04 – Object Identifier: messageDigest . . 31 16 Set (22 octets)

. . . 04 14 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx – Octet String (20 octets) SHA-1 digest

31 59 Set (89 octets)

. 30 18 Sequence (24 octets)

. . 06 09 2A 86 48 86 F7 0D 01 09 03 – Object Identifier: contentType . . 31 0B Set (11 octets)

. . . 06 09 2A 86 48 86 F7 0D 01 07 01 – Object identifier: pkcs7-data . 30 18 Sequence (24 octets)

. . 06 0A 2A 86 48 86 F7 0D 01 09 19 03 – Object Identifier: signerNonce . . 31 0A Set (10 octets)

. . . 04 O8 xx xx xx xx xx xx xx xx– Octet String: randomNonce . 30 23 Sequence (35 octets)

. . 06 09 2A 86 48 86 F7 0D 01 09 04 – Object Identifier: messageDigest . . 31 16 Set (22 octets)

. . . 04 14 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx – Octet String (20 octets) SHA-1 digest

4.2.2 Implémentation de l’application de téléchargement des fichiers signés