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
:
// 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:
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
----123456789--
| 
