|
|
|
|
|
En raison de la cryptographie haute qualité proposée par MOVEit Crypto avec validation Ipswitch FIPS 140-2 et de son utilisation intégrale dans MOVEit Transfer, MOVEit Transfer est sujet à des contrôles d'exportation cryptographique. Pour résumer, il est actuellement légal d'installer et d'utiliser MOVEit Transfer dans les pays non couverts par les documents « Regional Considerations » (Considérations régionales) du Département du Commerce des États-Unis.
Le reste de ce document est une réponse abrégée aux documents « Control Policy--CCL Based Controls » (Politique de contrôle--Contrôles basés sur la liste de contrôles relatifs aux commerce), « Supplement No. 6 to part 742 » (Supplément N°6 à la partie 742), « Export Administration Regulations » (Régulations de l'administration de l'exportation). (Le document complet est conservé au Département du Commerce des États-Unis.) Sur demande, la dernière mise à jour date du 15 mai 2002.
MOVEit Transfer et MOVEit Automation.
1. MOVEit Transfer utilise :
MOVEit Automation utilise également un chiffrement continu simple pour protéger les mots de passe stockés localement. Il s'agit d'un schéma basé sur rotor conçu spécialement pour être exportable en 1990, lorsque les réglementations étaient plus restrictives.
Hormis l'implémentation SSL fournie par Microsoft, les produits n'utilisent pas de chiffrement asymétrique.
2. MOVEit Transfer chiffre les fichiers avec une clé 256 bits.
Les algorithmes de gestion de clé pour le SSL sont bien documentés et ne seront pas exposés ici.
3. L'algorithme AES n'est pas propriétaire. Il a fait l'objet d'une validation FIPS 197 pour fonctionner conformément aux exigences des documents publics du NIST (National Institute of Standards and Technology - Institut national des normes et de la technologie) et du CSE (Communications Security Establishment - Centre de la sécurité des télécommunications).
(Le code source a été inspecté dans le cadre du processus de validation FIPS 140-2.)
L'algorithme basé sur rotor fonctionne de la manière suivante :
4. Avant le chiffrement, les données ne font l'objet d'aucun traitement préalable.
5. Pour le chiffrement AES, le texte chiffré est préfixé avec un en-tête 128 octets utilisé pour stocker un hachage de message, la taille du message d'origine ainsi que d'autres informations ne pouvant être stockées uniquement à l'aide de la structure de fichier du système d'exploitation sous-jacente.
Quant au schéma basé sur rotor, tel que décrit ci-dessus, l'encodage publiable RFC 1113 est appliqué.
6. Le TCP et le SSL sont pris en charge. Nous nous appuyons sur le logiciel Microsoft standard installé sur l'ordinateur de l'utilisateur.
7. Nous implémentons deux APIs internes uniquement.
Ces méthodes permettent de chiffrer et déchiffrer les fichiers sans avoir à les lire intégralement dans la mémoire. Pour convenir à la fois aux versions ASP et ASP.NET de Response.BinaryWrite, Ipswitch a implémenté les versions BSTR et SafeArray of Byte.
8. L'API qui utilise AES est implémentée à la fois par lien statique et par un objet COM, lié de façon dynamique. Le même code source est utilisé dans les deux cas.
Nous utilisons également TCP/IP Enterprise Edition de Dundas Software. Ce logiciel fournit du code dans une bibliothèque statique et dans une bibliothèque dynamique appelée UTSecureLayer.dll. Le véritable code de chiffrement n'est fourni ni par nous ni par Dundas ; c'est la bibliothèque CRYPT32.dll de Microsoft qui est utilisée. CRYPT32.dll est liée de façon dynamique et doit déjà être présente sur l'ordinateur de l'utilisateur. (Les produits MOVEit n'installent pas CRYPT32.dll.)
9. Nous n'utilisons pas de code d'octet Java.
10. Le produit est fourni compilé et lié aux fichiers .exe et .dll de Microsoft. Aucun contrôle de parité ni obfuscation spécifique n'est utilisé(e) pour empêcher l'édition binaire des fichiers.
1. - 4. Sans objet - nous ne vendons pas de composants.
1. - 3. Sans objet - nous ne cherchons pas à distribuer du code source.