VI.3.1. Service de sauvegarde
L'utilisation de SyncMl et du serveur Funambol sont un gage de
sécurité car ils gèrent de nativement la
sécurité des transactions.
Dans la phase d'authentification, le serveur envoie au client
un message contenant la balise <Chal> qui
représente une demande d'authentification (Challenge en
anglais) pour les informations auxquelles le client tente d'accéder. Le
client doit alors répondre et donner le login et mot de passe dans une
balise <Cred> (Credential en
anglais).
SyncML peut utiliser l'accès authentifié par le
hachage md5. Le client et le serveur échangent leurs identifiants durant
la phase d'authentification, retournant un code d'erreur si le processus
s'arrête quelque part. La balise <Cred> est
utilisée dans le <SyncHdr> pour fixer le type
d'authentification qui sera utilisé dans la phase d'authentification.
(Il y a le hachage md5, mais aussi l'encodage base64 et d'autres... Il faut
donc que le serveur informe le client du type d'authentification
utilisée).
Au niveau du serveur, la résolution des conflits de
synchronisation (modification d'une même donnée à la fois
sur le client et le serveur) revient à la charge du Sync Engine (moteur
de synchronisation) et s'effectue en s'appuyant sur les ancres.
VI.3.2 Paiement en ligne
La sécurité de ce module est totalement
assurée par le partenaire de paiement (Paybox). L'ensemble des phases de
paiement à réaliser entre l'acheteur et le système est
entièrement crypté et protégé. Le protocole
utilisé est SSL couplé à de la
monétique bancaire. Il nous suffit juste de nous mettre en HTTPS. Dans
ce cas, un cadenas fermé apparaît en bas de la fenêtre du
logiciel de navigation.
Génération des tickets
Pour s'assurer que le numéro
généré pour ce ticket est unique, nous utilisons la
fonction uniqid() de php : string uniqid (
string prefix , bool more_entropy )
Cette fonction retourne un identifiant préfixé
unique, basé sur l'heure courante, en micro-secondes. Le
paramètre prefix est optionnel mais peut servir à
identifier facilement différents hôtes, si nous
générons simultanément des fichiers depuis plusieurs
hôtes, à la même micro-seconde. Depuis PHP 4.3.1, prefix
peut prendre jusqu'à 114 caractères. Si le paramètre
optionnel more_entropy est TRUE , uniqid() ajoutera une
entropie "combined LCG" à la fin de la valeur retournée, ce qui
renforcera encore l'unicité de l'identifiant.
Sans prefix (préfixe vide), la chaîne
retournée fera 13 caractères. Si more_entropy est
à TRUE , elle fera 23 caractères. En combinant cette
méthode au hachage md5, nous obtenons un code de 32 caractères
:
59
Conception d'un service vidéo pour terminaux portables de
type Smartphones
Mémoire Ingénieur des Travaux des
Télécommunications-ESMT-Monjouo M. Rodrigue
// meilleur, difficile à deviner
$code = md5(uniqid(rand(), true));
Le code généré, ainsi que les autres
références du ticket, sont stockés au niveau de la base de
données. Un process java plus sécurisé se chargera de
parcourir la base et générer les tickets en instance. Une
génération avec un script php rendrait l'opération visible
au niveau de la page web.
MMS non transférables
Le MMS transmis à un bénéficiaire,
après une transaction, ne peut plus être utilisé par un
autre appareil mobile, en d'autres termes ce MMS ne peut plus être
transféré. Pour cela, l'Open Mobile Alliance (OMA) a
spécifié un modèle de gestion des droits [OMADRM], dont la
version 1 actuelle prévoit trois niveaux de protection :
· Niveau 1, Forward Lock :
- l'usage du contenu téléchargé est
illimité (ex : autant d'écoutes que l'on veut) - le contenu ne
peut être transmis.
· Niveau 2, Remise Combinée (Combined
Delivery) :
- l'usage du contenu téléchargé est
régi par des droits (ex : 3 écoutes maximum).
- les droits d'accès au contenu sont
véhiculés avec le contenu - le contenu ne peut être
transmis.
· Niveau 3, Remise Séparée (Separate
Delivery) :
- l'usage du contenu téléchargé est
régi par des droits (ex : 3 écoutes maximum).
- les droits d'accès au contenu sont
véhiculés indépendamment du contenu - le contenu peut
être transmis (sans les droits), possibilité de marketing
viral.
On doit néanmoins mettre l'accent sur le fait que tous
les terminaux n'ont pas encore intégré de mécanisme de
protection des droits. En outre, malgré la normalisation par l'OMA, il
existe encore un certain nombre de modèles ayant une
implémentation propriétaire des DRM. Cependant, un contenu
protégé par un DRM, mais envoyé sur un mobile ne
supportant pas ce DRM, est rejeté.
Une seconde version de DRM est prévue par l'OMA,
utilisant un cryptage des droits d'accès par une clé publique
(PKI).
Pour protéger un fichier par Combined Delivery (pour
rendre le message, entre autres, non transférable) celui-ci doit
être encapsulé dans une enveloppe de type :
application/ vnd.oma.drm.rights+xml
Exemple:
60
Conception d'un service vidéo pour terminaux portables de
type Smartphones
Projet CLIPCLAP -Monjouo M. Rodrigue Ing.
Télécom
Content-Type: application/vnd.oma.drm.rights+xml
boundary="----123456789"
----123456789
Content-Type: image/jpeg; name="Logo.jpg"
Content-Transfer-Encoding: base64
Content-Location: Logo.jpg
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcH
Bw8LCwkMEQ8S
etc.etc.etc.etc.etc.etc..etc.etc.etc.etc
etc.etc.etc.etc.etc.etc.etc.etc
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQ
oL/8QAtREA
61
----123456789--
Mémoire Ingénieur des Travaux des
Télécommunications-ESMT-Monjouo M. Rodrigue
Conception d'un service vidéo pour terminaux portables de
type Smartphones
| 
