Jitsi

1. Jitsi
‫قنبریان‬ ‫مهدیس‬

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 (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

4. 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

5. 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

6. 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

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 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

9. Designing Jitsi
 The three most important constraints :
 multi-protocol support
 cross-platform operation
 developer-friendliness
9

10. 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

11. 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

12. 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

13. Bundle Activation
13

14. 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

15. 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

16. Service Structure
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-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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

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 communications between only authorized
clients
 The action SendRequest
 An authorization mechanism is required before
any execution of the action SendRequest
26

27. 27
Activity diagram for sending an instant message

28. 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. 29
Authorization aspect

30. 30
Sending an instant message with authorization

31. 31
Sending an instant message with authorization