Jitsi
‫قنبریان‬ ‫مهدیس‬
Overview
 Introduction
 History
 Features
 Supported protocols
 Architecture
 Designing Jitsi
 Jitsi and the OSGi Framework
 Service Structure
 Protocol Provider Service
 Media Service
 Security
 Voice Privacy
 Chat Privacy
 Authorization
2
Introduction
 Jitsi (formerly SIP Communicator)
 A free and open source multiplatform
 voice (VoIP), videoconferencing and instant messaging
 for Windows, Linux, Mac OS X and Android
 Released under the terms of the
Apache Software License
3
History
 Started in 2003 in the context of a student project by
Emil Ivov at the University of Strasbourg
 An example video phone in the JAIN-SIP stack
 Used as an experimentation tool because of its support for
IPv6
 Adding support for protocols other than SIP
 In 2011, adding support for audio/video
communication over XMPP
 In 2014, "Jitsi + Ostel" scored 6 out of 7 points on the
Electronic Frontier Foundation's secure messaging
scorecard
4
Features
 Supports multiple operating systems
 Direct media connection establishment with the ICE
protocol
 File transfer for XMPP, AIM/ICQ, Windows Live
Messenger, YIM
 IPv6 support for SIP and XMPP
 Media relaying with the TURN protocol
5
Features
 Voice and video calls for SIP and XMPP using
H.264 and H.263 or VP8 for video encoding
 Wideband audio with SILK, G.722, Speex and
Opus
 Packet loss concealment with the SILK and Opus
codecs
6
Supported protocols
 MSNP (Microsoft Messenger service, commonly known as MSN,
.NET, or Live; no multimedia support)
 OSCAR (AIM/ICQ/MobileMe)
 SIP/SIMPLE
 XMPP/Jingle (Google Talk, LJ Talk, Gizmo5, Facebook Chat,
…)
 YMSG (YIM; only basic chat and file transfers)
7
Architecture
 Uses the Apache Felix OSGi implementation for
modularity
 Uses the JAIN-SIP protocol stack for SIP support
and the Jive Software Smack library for XMPP
 Complete an ICE implementation called ice4j.org
 Audio systems supported are PortAudio,
PulseAudio and WASAPI
8
Designing Jitsi
 The three most important constraints :
 multi-protocol support
 cross-platform operation
 developer-friendliness
9
Jitsi and the OSGi Framework
 OSGi is about modules
 Jitsi is a collection of OSGi bundles
 OSGi services
 representing the part of a bundle that is visible to everyone
else
 a group of Java interfaces that allow use of a specific
functionality
10
Jitsi and the OSGi Framework
 service implementation
 The classes that actually implement the functionality
 name of the service interface they implement, with an "Impl"
suffix at the end (e.g., ConfigurationServiceImpl).
 OSGi framework allows developers to hide service
implementations
11
Jitsi and the OSGi Framework
 Most bundles also have activators
 Activators are simple interfaces that define a start
and a stop method
 When calling these methods Felix passes them a parameter
called BundleContext
 The BundleContext gives bundles a way to connect
to the OSGi environment
12
Bundle Activation
13
Service Structure
 All services and implementations in Jitsi are
separated under these two packages
 service in net.java.sip.communicator.service
 package implementation in net.java.sip.communicator.impl
14
Service Structure
 register in the BundleContext and indicate that it
provides an implementation of the
ConfigurationService
 In net.java.sip.communicator.plugin
 keep bundles that use services defined by others but that
neither export nor implement any themselves
15
Service Structure
16
Protocol Provider Service
 The ProtocolProviderService in Jitsi defines the
way all protocol implementations behave
 The protocol service interfaces found under the
net.java.sip.communicator.service.protocol package
17
Media Service
 Real-time Transport Protocol (RTP)
 Actually move voice and video over the Internet
 SIP and XMPP are only responsible for preparing everything
that RTP needs
 MediaService and its implementation are located in
net.java.sip.communicator.service.neomedia and
net.java.sip.communicator.impl.neomedia
18
Security
 Encrypted password storage Password protection
with a master password
 Encrypted Instant Messaging with Off-the-Record
Messaging (OTRv4)
 Chat authentication with the Socialist Millionaire
Protocol over OTR

19
Security
 Call encryption with SRTP and ZRTP for XMPP
and SIP
 DNSSEC support
 TLS support and certificate-based client
authentication for SIP and XMPP
20
Voice Privacy
 ZRTP make encrypted phone calls over the
Internet
 uses three phases
 Discovery phase - detecting if the peers supports ZRTP
 Key agreement phase - exchanging the key material
 Secure phase - confirm the cryptographic data and switch to
SRTP mode
 ZRTP is not a replacement of SRTP but an enabler
to use SRTP in an easy way
21
Voice Privacy
 GNU ZRTP supports two authentication
algorithms:
 HMAC-SHA1 which supports authentication lengths of 32
and 80 bit
 Skein MAC which supports authentication lengths of 32 and
64 bit
22
Voice Privacy
 ZRTP uses the RTP session to exchange its data
 The Diffie-Helman key agreement protocol is
vulnerable to a Man-in-the-Middle (MitM) attack
 To overcome this problem ZRTP defines counter measures
to enable the users to detect a MitM
23
Chat Privacy
 Off-the-record Messaging (OTR) cryptographic
protocol
 Provides strong encryption for instant messaging
conversations
 Uses a combination of
 the AES symmetric-key algorithm
 the Diffie–Hellman key exchange
 the SHA-1 hash function
24
Chat Privacy
 Providing:
 encryption and authentication
 Forward secrecy
 Deniable authentication
 supports mutual authentication of users using a
shared secret through the socialist millionaire
protocol
 avoid a man-in-the-middle attack
25
Authorization
 Allow communications between only authorized
clients
 The action SendRequest
 An authorization mechanism is required before
any execution of the action SendRequest
26
27
Activity diagram for sending an instant message
Authorization
 The authorization aspect
 Specifies an access control behavior
 AddCheckPermission
 injects the authorization behavior as a structured activity
node before any SensitiveMethod
 Application-independent and must be specialized
by the developer
28
29
Authorization aspect
30
Sending an instant message with authorization
31
Sending an instant message with authorization

Jitsi

  • 1.
  • 2.
    Overview  Introduction  History Features  Supported protocols  Architecture  Designing Jitsi  Jitsi and the OSGi Framework  Service Structure  Protocol Provider Service  Media Service  Security  Voice Privacy  Chat Privacy  Authorization 2
  • 3.
    Introduction  Jitsi (formerlySIP Communicator)  A free and open source multiplatform  voice (VoIP), videoconferencing and instant messaging  for Windows, Linux, Mac OS X and Android  Released under the terms of the Apache Software License 3
  • 4.
    History  Started in2003 in the context of a student project by Emil Ivov at the University of Strasbourg  An example video phone in the JAIN-SIP stack  Used as an experimentation tool because of its support for IPv6  Adding support for protocols other than SIP  In 2011, adding support for audio/video communication over XMPP  In 2014, "Jitsi + Ostel" scored 6 out of 7 points on the Electronic Frontier Foundation's secure messaging scorecard 4
  • 5.
    Features  Supports multipleoperating systems  Direct media connection establishment with the ICE protocol  File transfer for XMPP, AIM/ICQ, Windows Live Messenger, YIM  IPv6 support for SIP and XMPP  Media relaying with the TURN protocol 5
  • 6.
    Features  Voice andvideo calls for SIP and XMPP using H.264 and H.263 or VP8 for video encoding  Wideband audio with SILK, G.722, Speex and Opus  Packet loss concealment with the SILK and Opus codecs 6
  • 7.
    Supported protocols  MSNP(Microsoft Messenger service, commonly known as MSN, .NET, or Live; no multimedia support)  OSCAR (AIM/ICQ/MobileMe)  SIP/SIMPLE  XMPP/Jingle (Google Talk, LJ Talk, Gizmo5, Facebook Chat, …)  YMSG (YIM; only basic chat and file transfers) 7
  • 8.
    Architecture  Uses theApache Felix OSGi implementation for modularity  Uses the JAIN-SIP protocol stack for SIP support and the Jive Software Smack library for XMPP  Complete an ICE implementation called ice4j.org  Audio systems supported are PortAudio, PulseAudio and WASAPI 8
  • 9.
    Designing Jitsi  Thethree most important constraints :  multi-protocol support  cross-platform operation  developer-friendliness 9
  • 10.
    Jitsi and theOSGi Framework  OSGi is about modules  Jitsi is a collection of OSGi bundles  OSGi services  representing the part of a bundle that is visible to everyone else  a group of Java interfaces that allow use of a specific functionality 10
  • 11.
    Jitsi and theOSGi Framework  service implementation  The classes that actually implement the functionality  name of the service interface they implement, with an "Impl" suffix at the end (e.g., ConfigurationServiceImpl).  OSGi framework allows developers to hide service implementations 11
  • 12.
    Jitsi and theOSGi Framework  Most bundles also have activators  Activators are simple interfaces that define a start and a stop method  When calling these methods Felix passes them a parameter called BundleContext  The BundleContext gives bundles a way to connect to the OSGi environment 12
  • 13.
  • 14.
    Service Structure  Allservices and implementations in Jitsi are separated under these two packages  service in net.java.sip.communicator.service  package implementation in net.java.sip.communicator.impl 14
  • 15.
    Service Structure  registerin the BundleContext and indicate that it provides an implementation of the ConfigurationService  In net.java.sip.communicator.plugin  keep bundles that use services defined by others but that neither export nor implement any themselves 15
  • 16.
  • 17.
    Protocol Provider Service The ProtocolProviderService in Jitsi defines the way all protocol implementations behave  The protocol service interfaces found under the net.java.sip.communicator.service.protocol package 17
  • 18.
    Media Service  Real-timeTransport Protocol (RTP)  Actually move voice and video over the Internet  SIP and XMPP are only responsible for preparing everything that RTP needs  MediaService and its implementation are located in net.java.sip.communicator.service.neomedia and net.java.sip.communicator.impl.neomedia 18
  • 19.
    Security  Encrypted passwordstorage Password protection with a master password  Encrypted Instant Messaging with Off-the-Record Messaging (OTRv4)  Chat authentication with the Socialist Millionaire Protocol over OTR  19
  • 20.
    Security  Call encryptionwith SRTP and ZRTP for XMPP and SIP  DNSSEC support  TLS support and certificate-based client authentication for SIP and XMPP 20
  • 21.
    Voice Privacy  ZRTPmake encrypted phone calls over the Internet  uses three phases  Discovery phase - detecting if the peers supports ZRTP  Key agreement phase - exchanging the key material  Secure phase - confirm the cryptographic data and switch to SRTP mode  ZRTP is not a replacement of SRTP but an enabler to use SRTP in an easy way 21
  • 22.
    Voice Privacy  GNUZRTP supports two authentication algorithms:  HMAC-SHA1 which supports authentication lengths of 32 and 80 bit  Skein MAC which supports authentication lengths of 32 and 64 bit 22
  • 23.
    Voice Privacy  ZRTPuses the RTP session to exchange its data  The Diffie-Helman key agreement protocol is vulnerable to a Man-in-the-Middle (MitM) attack  To overcome this problem ZRTP defines counter measures to enable the users to detect a MitM 23
  • 24.
    Chat Privacy  Off-the-recordMessaging (OTR) cryptographic protocol  Provides strong encryption for instant messaging conversations  Uses a combination of  the AES symmetric-key algorithm  the Diffie–Hellman key exchange  the SHA-1 hash function 24
  • 25.
    Chat Privacy  Providing: encryption and authentication  Forward secrecy  Deniable authentication  supports mutual authentication of users using a shared secret through the socialist millionaire protocol  avoid a man-in-the-middle attack 25
  • 26.
    Authorization  Allow communicationsbetween only authorized clients  The action SendRequest  An authorization mechanism is required before any execution of the action SendRequest 26
  • 27.
    27 Activity diagram forsending an instant message
  • 28.
    Authorization  The authorizationaspect  Specifies an access control behavior  AddCheckPermission  injects the authorization behavior as a structured activity node before any SensitiveMethod  Application-independent and must be specialized by the developer 28
  • 29.
  • 30.
    30 Sending an instantmessage with authorization
  • 31.
    31 Sending an instantmessage with authorization