Samsung KNOX : ça passe pour l’ANSSI malgré quelques soucis

« Des comportements limites ont été relevés, mais ne remettent toutefois pas en cause la sécurité globale de la solution pour le cas d’usage considéré ».

Cette remarque figure au point 2.3.7 du rapport de certification – document PDF, 16 pages – établi par Trusted Labs à l’issue d’un audit de Samsung KNOX.

Le fournisseur de systèmes de sécurité basé à Meudon (Hauts-de-Seine) avait été sollicité par l’ANSSI en tant que partenaire de confiance dans le cadre du programme de Certification sécuritaire de premier niveau (CSPN), mis en place en 2008 comme une alternative aux évaluations Critères Communs.

Conformément au principe du CSPN et en respect du décret 2002-535 du 18 avril 2002 modifié relatif à la « certification de la sécurité offerte par les produits et les systèmes de technologies de l’information », les tests n’ont pas porté sur l’ensemble de KNOX.

Les équipes de Trusted Labs se sont en l’occurrence concentrées sur les fonctionnalités assurant l’isolation et le cloisonnement dynamiques des applications installées dans des environnements (ou conteneurs) différents.

« Comportements limites »

Cinq éléments ont plus particulièrement été examinés : l’isolation des données, le filtrage des applications, la gestion de l’état du conteneur et la gestion de l’accès aux interfaces externes. Le tout par l’intermédiaire de tests en « boîte noire », effectués en temps et délais contraints, encore une fois selon le cadre posé par le CSPN.

Quatre téléphones ont été utilisés : deux Galaxy Note 4 (SM-N910F) et deux Galaxy S5 (SM-G900F) équipés d’Android 5.0.0 et 5.0.1.

La charge de travail a été évaluée à 40 hommes jours pour mettre à l’épreuve le « mécanisme de cloisonnement runtime de KNOX Workspace version 2.3 » (mention qui figure sur le certificat ANSSI-CSPN-2015/07 délivré à Samsung en date du 3 décembre 2015).

Les « comportements limites » dont il est question portent sur la gestion des autorisations et sur l’authentification des utilisateurs.

Dans le premier cas, le système de filtrage des applications et équipements repose sur un système de listes blanches et noires « pouvant porter à confusion ». Il faut, selon Trusted Labs, une « bonne compréhension du mécanisme » et une « configuration rigoureuse ».

Concernant l’authentification, elle n’a pas eu, dans certains cas, le comportement attendu, sans toutefois remettre en cause la « conformité globale de la fonction ».

Pas sans faille

Remarque complémentaire : « Le temps minimal d’activité au bout duquel un conteneur est verrouillé est fixé à 5 min [sic] ; un temps plus court (de l’ordre de 30s voire 1min) [sic] offrirait un meilleur niveau de sécurité ».

On notera que les fonctions de sécurité étudiées sont jugées résistantes contre des attaques de niveau « modéré ».

Certaines vulnérabilités connues d’Android ont été testées, mais elles se sont trouvées non applicables à la version utilisée pour l’évaluation.

Il existe une faille qui n’est pas considérée comme critique à condition de respecter certaines conditions, notamment la vigilance de l’utilisateur lors du basculement entre un conteneur et une application externe.

C’est précisément sur ce point que porte la faiblesse : un utilisateur qui lance un processus de changement de code PIN ou de méthode d’authentification dans un conteneur peut en sortir, puis y revenir sans qu’il lui soit demandé de se « réauthentifier ». Il peut alors définir un nouveau code PIN ou une nouvelle méthode d’authentification sans saisir le code actuel.

Crédit photo : Andrey_Popov – Shutterstock.com