Zfone : Téléphonie IP sécurisée sous Linux

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
15
mar.
2006
Sécurité
Philip Zimmermann, le créateur de PGP vient de créer Zfone, un projet de protocole et de logiciel visant à sécuriser les communications VoIP basées sur le protocole standard ouvert SIP. La première version beta fonctionne uniquement sous Linux et Mac OS X.

Basé sur un système de clés, Zfone détecte quand la communication est initialisée et génère une paire de clés entre les deux parties. Le chiffrement et le déchiffrement de la communication sont effectués à la volée. De plus, une petite interface graphique ayant pour but d'informer l'utilisateur sur la sécurité de la communication a été créée.

Zfone devrait fonctionner avec la plupart des clients VoIP compatibles SIP tels que Ekiga, WengoPhone ou Gizmo. Le protocole Zfone devrait apparaître peu à peu en standard dans certains clients VoIP pour autant que la licence le permette. En effet, si les sources sont disponibles pour Linux (il faut fournir une adresse email pour pouvoir télécharger), la licence n'est pas encore déterminée. Certaines parties de code sont soumises à un copyright détenu par Phil Zimmermann & Associates LLC.

Note : La version Windows est annoncée pour mi-avril.

NdM : Merci à jcs d'avoir proposé une dépêche complémentaire. Zfone se place comme un filtre (au niveau de la couche IP du système d'exploitation) entre le logiciel de téléphonie et Internet en interceptant les paquets SIP pour effectuer le chiffrement. Zfone a été testé avec les logiciels propriétaires X-Lite, Gizmo et SJphone.

Selon Philip Zimmermann, Zfone a l'avantage de ne pas se baser sur les architectures complexes à mettre en oeuvre telles que PKI, certificats X.509, autorités de confiance... qui ont - selon lui - empêché le décollage du mail sécurisé.

Le protocole utilisé, qui a été baptisé ZRTP, permet d'effectuer un échange de clés (key agreement en anglais) Diffie-Hellman dans un paquet RTP lors de l'intialisation de la communication. Le secret partagé ainsi obtenu entre les deux clients est ensuite utilisé pour initialiser une session SRTP (Secure RTP). ZRTP est donc parfaitement interopérable avec tous les logiciels utilisant le protocole SIP.

Le document décrivant ZRTP, co-écrit avec Alan Johnston (également co-auteur de la RFC 3261 qui définit le protocole SIP) et Jon Callas, directeur technique de PGP Corporation, a été proposé pour standardisation à l'IETF.

Aller plus loin

  • # Questions techniques : overhead +Jingle/H.323

    Posté par  (site web personnel) . Évalué à 3.

    Combien d'overhead engendre cette couche de crypto au niveau CPU autant qu'au niveau réseau ?

    Ensuite, fonctionne-t-il (est-il facilement adaptable) sur les protocoles Jingle et H.323 ?

    • [^] # Re: Questions techniques : overhead +Jingle/H.323

      Posté par  (site web personnel) . Évalué à 4.

      Combien d'overhead engendre cette couche de crypto au niveau CPU autant qu'au niveau réseau ?

      À la louche, c'est faible. Les algo de chiffrement de flux (stream cipher) ne sont pas réputés pour être très rapides mais sur un PC actuel, ils peuvent cracher 1Mo/s en consommant moins de 1% du CPU. On est plus rapidement limité par son accès au net que par le CPU.

      Au niveau réseau, l'échange de clé demande l'échange de quelques paquets. Mais il faudrait regarder en détail le protocole pour savoir combien de temps prend le Diffie-Hellman. Enfin au pire on a une petite latence lors de l'établissement de la connexion.

  • # ssl

    Posté par  . Évalué à 3.

    Une question bete, le fux sip transite bien par du udp ou du tcp.
    Dans ce cas pourquoi ne pas securiser avec TLS/DTLS ?

    • [^] # Re: ssl

      Posté par  . Évalué à 2.

      d'ailleurs d'apres http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html le DTLS est deja implementé dans des stacks sip...

    • [^] # Re: ssl

      Posté par  . Évalué à 10.

      SIP possède déjà un modèle de chiffrement TLS pour le mode TCP et on peut si l'on veut chiffrer avec DTLS aussi.
      Mais ce n'est pas SIP qui est chifrée ici, c'est la couche RTP... qui est plus ou moins indépendante de SIP vu que RTP est aussi utilisé dans H323 et bien d'autres protocoles de communication.
      SIP est un protocole de signalisation d'appels, il n'encapsule pas les flux audios et vidéos. Les flux SIP transitent via des proxys SIP tandis que les flux RTP transitent généralement en Pear to Pear.
      Voilà pourquoi une extension à RTP est proposée, elle permet une standardisation des échanges audios sécurisés, permettant l'interropérabilité des clients SIP (et pourquoi pas aussi aussi des clients H323).

      • [^] # Re: ssl

        Posté par  . Évalué à 10.

        les flux RTP transitent généralement en Pear to Pear

        Pour améliorer le transit des flux, mangez des poires ?

      • [^] # Re: ssl

        Posté par  . Évalué à 3.

        Mais la couche rtp c'est de l'udp.
        Pourquoi on ne peut pas utiliser DTLS dessus ?

        • [^] # Re: ssl

          Posté par  . Évalué à 6.

          Bah, en fait faut savoir que le chiffrement DTLS (tout comme TLS) necessite un PKI (public key infrastructure)... et comme c'est un système centralisé, il faut le gérer...et plus il grossit plus il devient sujet aux problèmes de révocations et aux attaques (car même si le système d'échange de clef et de certificats est très robuste aux attaques, le PKI en lui même ne l'est pas forcément, et c'est ici que se trouve la faille du système).
          Donc ZRTP propose une variante pour l'échange le chiffrement Diffie-Hellman en ajoutant un SAS (short authentication string) avec un hash associé... ce qui permet de se passer du PKI.
          L'idée est de ne plus dépendre d'un PKI et pour le monde du libre je trouve que la solution proposée n'est pas anodine et plutôt adaptée aux projets indépendants les uns des autres.
          Car sinon chaque client devraient être géré par le même PKI ou bien pouvoir en faire cohabiter plusieurs à la fois ce qui devient le bordel car on a alors une tonne de certificats dont on a rien faire!

    • [^] # Re: ssl

      Posté par  (site web personnel) . Évalué à 3.

      On pourrait aussi utiliser IPsec/IKE au lieu de SRTP/ZRTP pour chiffrer les paquets IP. Mais c'est l'habitude de Philip Zimmermann de tout refaire à partir de zéro.

      • [^] # Re: ssl

        Posté par  . Évalué à 0.

        IPsec/IKE y'a pas plus pratique pour etre sur que ce soit pas interroperable, supporte mal le nat, soit mal implémenté ...
        Je ne dis pas que réinventer a chaque fois c'est bien, mais ipsec ...

  • # Licence

    Posté par  (site web personnel) . Évalué à 7.

    la licence n'est pas encore déterminée.


    Cette partie de l'info est surprennante. La licence est cette sorte de contrat qui est échangé entre le fournisseur et l'utilisateur. Pour moi, à partir du moment oùu il y a échange de logiciel (y compris sous forme de source) il y a une licence (un contrat) quand bien même elle serait implicite.

    J'imagine donc qu'actuellement, c'est le droit d'auteur qui s'applique. Mais quel droit d'auteur ? De quel pays ?

    Me paraît suspect voire dangeureux cette histoire.
    Je connais des cas où, lorsque l'on demande à voir les sources d'un logiciel, le contrat qui est passé avec l'auteur consiste à accepter de ne jamais plus travailler dans ce domaine (enfin, je déforme, mais l'idée est là).

    Attention donc, la licence protège aussi bien l'auteur que l'utilisateur.

  • # Sécurisation

    Posté par  . Évalué à 1.

    Sur le principe de la sécurisation des appels, Phonesystems.net a lancé il y a quelques temps une option de sécurisation des lignes dans ses forfaits.

    "Elle permet le cryptage SecureRTP de votre voix ainsi que celle de votre interlocuteur en utilisant une clé de 128 bits.

    Le cryptage est disponible pour les appels sortants et entrants (en dehors de la Messagerie Vocale) entre :

    - Deux terminaux VoIP Linksys bénéficiant de cette option

    - Un terminal VoIP Linksys et le réseau téléphonique public (fixe, mobile, national et international)"

    Et comme SJPhone par exemple fonctionne avec une ligne Phonesystems il n'y a pas besoins de rajouter Zfone.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.