an innovative use case dedicated to the development .... the vulnerabilities of WordPress plugins showed that .... We first build a WebRTC platform able to.
*Authors Version* Certified multimedia statement with WebRTC and Microservices [This paper has been accepted in the 2nd Asia Pacific Conference on Multimedia and Broadcasting (APMediaCast2016) will be held on November 17-19, 2016, in Bali, Indonesia] [This file is an author version for personal record.] Ahmed BOUABDALLAH and Saad EL JAOUHARI {ahmed.bouabdallah,saad.eljaouhari}@telecom-bretagne.eu Institut Mines-Telecom / TELECOM Bretagne Network, Security and Multimedia department Site of Rennes, FRANCE
Abstract—The articulation between WebRTC and microservices deserves more attention and we argue that it could be highly promising. We illustrate it by the introduction, the analysis and the implementation of an innovative use case dedicated to the development of multimedia statements certified in a fair way. The generic character of this use case allows a rich set of instantiations covering various real life situations involving remote multimedia conversational exchanges. Our approach however required the development of several non trivial microservices. We thus point that the emerging of a dynamic ecosystem able to successfully deepen in this direction the full capabilities of WebRTC, might suffer from the lack of microservices off the shelf. We finally address this problematics of microservices deployment by identifying and discussing two alternatives solutions.
I. I NTRODUCTION WebRTC overcame the challenge of converging into a single technology two traditionally opposite sides of the Web represented by the asynchronous clientserver paradigm on one hand, and the domain of the peer-to-peer multimedia and real-time communications on the other hand. It is technically an open-source web-based application exploiting dedicated native APIs implemented in the browser, which allows the exchange of media and data in real time and in a peerto-peer fashion. We thus argue that WebRTC represents a significant breakthrough whose possibilities began to be hardly perceived. We introduce in this way an innovative family of use cases related to the various certified multimedia statements that a user can perform during an ongoing WebRTC session. These statements can be needed for different purposes (private, administrative, public or professional). The current functionalities of WebRTC however do not provide these kind of features. For this purpose we
propose to extend it with new and customized features, which can be suggested by the developer or a provider, without the need to change the current WebRTC architecture. Let us first recall the traditional functioning of a statement establishment. Suppose that at some point, Alice wants to make a particular statement, intended for Bob, who will consider it important. To allow Bob to preserve a trace of this declaration, Alice usually has first to write it, to timestamp it and to sign it; then she usually makes it reviewed and countersigned by Bob and the eventual other present persons who would then act as witnesses. The document so obtained is often called statement, report or minutes, we will call it in this work CS (Certified Statement). Suppose now that such a statement has been achieved during a WebRTC session between Alice and Bob. We argue that the ability to produce in a fair distributed way a digital CS, represents an innovative and non-trivial usage of WebRTC. We identify two main roles involved in a CS, the declarer as the one who establishes the statement (Alice), and the observer instantiated by the other participants (Bob and the eventual witnesses). We define the profile of the CS as an abstract structure containing at least the identities of the persons involved in the statement with their respective role as well as the availability and the characteristics of the recording capacities in each extremity. It would be possible to enrich this profile by adding contextual informations about the declaration (date, location, . . . ). This profile appears as a contractual framework between the different actors involved in the statement. The proof of their approval can be represented by their digital
signature of the profile. Finally a valid CS must contains the timestamped and signed statement with its associated signed profile. The generic character of this use case allows a rich set of instantiations covering remote business meeting, remote oral school exam, remote medical consultation, remote negotiation of a contract, remote filing of a complaint in front of a police officer, remote summons in front of a judge, . . . We can moreover extend it by introducing for example several statements done by different declarers in the same session. Another interesting use case can be derived from the previous one, and which consists in producing a synthesis of the session instead of its integral record (contract, summary . . . ). The rest of the paper is structured as follows. Section II introduces a model of certified multimedia statement. Section III discusses the required technical means. The new concept of microservice is presented in IV and we show in section V its exploitation to implement our use case. We finally identify and develop in section VI a new problematics related to off the shelf microservices deployment. The conclusion with a description of our future works conclude our paper in section VII.
Fig. 1. Creation of a valid CS
As shown in the figure above, the creation of the CS goes through several steps: Step 1 : AuthA creates the statement profile, which MUST be then signed by all the participants on both sides. We have to use a distributed signature protocol, represented in the figure by the first black box. The result will be a signed profile, obtained with a fair process [2], [3]. Step 2 : The declarer records his statement (Annot. Dec), we need to request a timestamp time from a Time Stamping Authority (TSA) [4]. The result is H = (Dec, time). Step 3 : Similarly, the signing of H is done again via a distributed signature protocol, represented by the second black box.
II. C ERTIFIED MULTIMEDIA STATEMENT MODEL
The definition of a general model of a certified multimedia statement requires some preliminary definitions. We call A the initiator side of the underlying WebRTC session, and B the other side of the session. The WebRTC system allows to authenticate AuthA the initiator of the session on A’s side together with AuthB the recipient of the session on B’s side [1]. We define DA and OA (resp. DB and OB ) the set of declarers and observers on side A (resp. on side B). For a sake of simplicity we present below the case where we have only one declarer located on side A, together with the recording capability (DA = {Alice} and DB = ∅).The following figure shows the course of the procedure to create a valid CS:
Step 4 : The final CS will be thus composed of the timestamped and signed recording (Dec), the timestamp (time) and the signed profile. The main challenge in designing a certified distributed statement rests on the level of trust between the different participants. It has been solved with the external authentication capabilities added to the WebRTC one, and with the introduction of fair contract signing protocols, the properties of which ensure the validity of the CS in the worst case when there is no trust between the participants. The other main challenge raises from the limited software capacities of the current WebRTC platform. Indeed native WebRTC does not propose dedicated functionalities such as signing, hashing, timestamping, etc. We propose in what follows to add theses new functionalities to WebRTC without modifying the architecture [5]. The next section makes a comparison between the different possible approaches, and present the one that fits to our needs.
III. A DDING FEATURES TO W EB RTC A. WebRTC First, let’s start with a small introduction of the WebRTC architecture, since it is the main brick of the proposed use case. As described in many RFCs, WebRTC allows real-time peer-to-peer communication between multiple users connected just with their browsers. Both media and data can be transfered directly and securely between peers. This technology is still under standardization by IETF and W3C [6], [5]. WebRTC uses mainly three APIs. MediaStream is responsible of the access to Input/Output devices and of the creation of the media stream. RTCPeerConnection is responsible of the creation of a secure media channel via SRTP (Secure Real-time Transport Protocol); it also encompasses signaling, NAT traversal and other important tasks. Finally RTCDataChannel allows the creation of a secure data channel via SCTP (Stream Control Transmission Protocol) encapsulated in DTLS (Datagram Transport Layer Security). B. The different approaches We analyze below two main technologies we identified, and which are likely to solve our objective. Plugins have the ability to add new features to a given web application or website. They are widely used in the web domain, since they offer a various number of features, helping developers to extend their applications. They are relatively simple to add and they usually execute a specific task. This solution has however many drawbacks. Plugins can be hard and complex to implement, by the way the most interesting ones are obviously not free. A vulnerable plugin may moreover threaten the whole system and break the privacy and the security of the user. An analysis of the vulnerabilities of WordPress plugins showed that from 322 downloaded plugins, 860 vulnerabilities have been discovered in 127 of them [7], [8], [9]. Last but not least plugins communication, update, maintainability and backward compatibility are usually complex procedures. Microservices is a new approach of developing small applications dedicated to the execution of one precise task. They are able to communicate and collaborate in order to build even a huge application like Amazon, Netflix and LinkedIn [10]. These ones evolved form a monolithic architecture to a microservice based design 1 . We investigate in this work this promising technology which seems to bring a better compromise
in terms of simplicity of development and deployment, scalability, security, and communication capabilities 1 . Microservices can be compared to Java applets, which may appear as their ancestors. They however do not suffer from the same defects. The inconvenience of Java applets is indeed their dependencies with the Java Runtime Environment, which has to be installed in the browser while maintaining the consistency of its version number. Java applets are also of limited interest because they are not supported by the mobile browsers as pointed in 2 . IV. M ICROSERVICES Traditionally a software application is developed as a single monolithic unit containing thousands of code lines. The inevitable evolution of such a software which may be required for various reasons (scalability, extendability, interoperability . . . ) can become hardly difficult due to its huge size. Microservices appear as an interesting emerging paradigm to solve those issues. A microservice is a lightweight code program, usually executing one particular task and which can cooperate and communicate with other ones using a simple transport protocol such as HTTP or TCP. The main idea is to be able to change a part of an application, just by changing the appropriate microservice. The brought gains are better resilience and replaceability properties of the global application 1 [11]. Microservices deployment can rest on containers technologies (Docker, Sandbox, . . . ), depending on policies varying from ”each microservice instance inside it’s own container” to ”all microservices’ instances in the same container” 3 . The development of microservices can be done using different technologies and programming languages. Some already adapted frameworks and toolkits exist allowing fast development. We may point MicroService4Net4 , KumuluzEE 5 and Seneca 6 . Seneca has been selected due to compatibility purposes with the WebRTC platform. Seneca is a Node.js toolkit with multiple built-in plugins that can be imported from its libraries 6 . It provides a rich framework allowing the developers to directly focus on the business logic. The core features of Seneca are transport independence and pattern matching of requests. They contribute to 2 http://www.java.com/en/download/faq/java
4 https://github.com/TheCodeCleaner/MicroService4Net 5 https://ee.kumuluz.com/
1 http://martinfowler.com/articles/microservices.html
mobile.xml
3 https://www.nginx.com/blog/deploying-microservices/
6 http:/senecajs.org
the simplification of the communication between microservices, on one hand by providing a rich set of communication primitives, the complexity of which is completely hidden, and on the other hand by using a pattern matching process applied to asynchronous messages expressed as JSON objects. The asynchronous event-based architecture of Seneca, associated with its pattern matching process solves in an elegant way the issue of microservices composition to build complex applications : once a microservice finishes its task it sends a request with a defined pattern and waits for the response; if a microservice matches this pattern, it generates the response and so on and so forth. Despite its undeniable and remarkable industrial success, Seneca’s main inconvenient comes from its lack of practical documentation and from the limited number of examples. We may also point another limitation due to the absence of open source testing and validation tools. Mastering the behavior of an application inducing collaborating microservices may quickly become intractable when their respective number and dependencies increase.
V. C ERTIFIED MULTIMEDIA STATEMENT IMPLEMENTATION
We first define the necessary functionalities needed for the targeted use case. We suppose that we have only two users, where Alice records her statement, timestamps it, signs it and then sends it to Bob, who in turn verifies the signature, and countersigns the statement if he agrees. Alice and Bob owning their respective private/public keys, represent the endpoints of the ongoing WebRTC session. Each identified functionality is provided by a dedicated microservice we have successfully implemented with Seneca : recording, hashing, timestamping, and signing. We implemented a prototype of the certified statement use case using Node.js. We first build a WebRTC platform able to exchange multimedia flows using the RTCPeerConnection API and data flows using the DataChannel API. The management of the identity of the users has also been considered by adding the Identity Provider entity to the platform using Persona IdP developed by Mozilla 7 . The following call flow summarizes the interactions between the users and the microservices, due to the lack of place we omit the profile establishment :
7 https://developer.mozilla.org/fr/docs/Web/API/RTCPeerConnection
Fig. 2. Call flow for signing a user statement using microservices
The microservices are deployed locally in the client side, each one in its own process listening on a dedicated port. An API implemented to manage the different requests plays the role of the orchestrator as shown in the next figure. The different microservices collaborate in order to perform the global use case. Alice needs only to trigger the recording of the ”Statement”, which once finished is sent to the hash microservice, that will compute the hash of the record ”H = hash(Statement)”. Then the timestamp ”time” will be retrieved from the Timestamp Authority (TSA), and another global hash ”H 0 = hash(H, time)” is computed. Finally H 0 is signed with Alice’s private key (P KA ) and we get the signed statement (SS) ”SS = signP KA (H 0 )”. SS, the timestamp, and the statement are sent to Bob. This one verifies the signature of SS and its integrity, then proceeds to the countersigning of the statement, using his private key P KB , and sends it to Alice who in turn verifies the received signature.
Fig. 3. Certified statement with microservices
VI. D EPLOYMENT ISSUES A. Problematics As shown in the previous sections, the articulation between WebRTC and microservices is highly promising, because it should allow to exploit the full capabilities of WebRTC, by the development of innovative use cases which are still to be explored. We may however point that the analysis of the certified multimedia statement use case required the development of several non-trivial microservices. Our approach indeed suffered from the lack of microservices off the shelf. Such unavailability might become a real bottleneck for the emerging of a dynamic ecosystem able to successfully deepen the full capabilities of WebRTC. It makes therefore sense to analyze this new capability defined by the provision of microservices off the shelf, we call it Microservice Provider (MSP). The lesson gained by the analysis of our use case leads us to identify two main alternatives to solve this problematics : remote vs local execution of the microservices. The first one rests on the classical SaaS model, while the second requires the definition of a dedicated architecture. B. Microservices provisioned through SaaS Software as a Service (SaaS), called also ”on-demand software”, is a paradigm where a user can remotely access a software hosted in a cloud infrastructure of a certain provider. The main advantage of SaaS consists in liberating the user from tedious tasks as managing, updating, monitoring . . . the applications he needs [12]. More and more software service providers jump into the SaaS model for gaining new profits. Microservices can naturally be integrated in the portfolio of a SaaS operator, without changing his underlying business model. All the complexity of the deployment, orchestration and the security of the microservices will be hidden in the business logic of the SaaS operator. The communication between the WebRTC platform and the SaaS operator must be secured using an encrypted channel (HTTPS, WebSocket Secure,. . . ). The call flow below shows the basic pattern of interactions involving a remote execution of a microservice :
C. Distribution of microservices 1) A basic architecture : In this approach a microservice is downloaded and locally executed in the user environment using dedicated containers. The figure below shows a basic architecture with several MSP to which a user may access to select the microservice of interest. The internal structure of such an MSP is currently investigated in the European reTHINK project [13].
Fig. 5. WebRTC/Microservice architecture
Downloading the microservice from the MSP requires a preliminary authentication of the user. The exchange between the user and the MSP must be protected; secured WebSocket channel can be used to prevent tempering and eavesdropping. The following figure shows the necessary interactions between the user and the MSP :
Fig. 6. Local execution of a downloaded microservice
2) Security concerns : The security in WebRTC has been natively considered by the working group who conceived a robust security architecture in order to provide, authentication, authorization, privacy, and data integrity [1],[14].
Fig. 4. Remote execution of SaaS hosted microservices
Concerning the microservices, we need to add Cross-origin resource sharing (CORS) [15], since the different parts of the architecture are not in the same domains and by the way do not respect the principles of the Same Origin Policies. Depending on the level
of trust in the MSP, we can add some exceptions on the origin of the microservices in the application, to allow such interactions. 3) Delegated access to microservices : Since every user has access to a set of microservices provided by the affiliated MSP, the access to others microservices is prohibited. However we can include the possibility of delegating access to a microservice, obviously with the authorization of owner. Many technology can be used in order to delegate access, for instance OAuth2, Kerberos, OpenID connect, . . . In our tests we used OAuth2 [16]. A simple example illustrating this solution is explained in the following figure :
Fig. 7. WebRTC architecture with a delegated access to microservices
In an ongoing WebRTC session where Alice is communicating with Bob, they both are registered within an MSP and have access to their respective set of microservices. However Alice does not have the right to access the microservice MS1 (cf. Fig.7) belonging to Bob, in this case Alice can ask Bob for a delegated access to MS1 for a certain period of time guaranteed by the Token. 4) Business model : The pricing strategies used in SaaS [17] are an interesting starting point. Each user has to be registered in a MSP. Several pricing models can be used depending on the company’s preferences. For example the Freemium model which is one of the most popular model used by SaaS companies, offers the basic features for free, and other sophisticated paying features. The user can subscribe in one of the proposed formulas for getting or accessing the wanted microservice. VII. C ONCLUSION AND FUTURE WORKS In this paper we have introduced an innovative use case investigating the different kinds of certified statements that a user can perform during a WebRTC session. We presented a proposal to extend the functionalities of WebRTC without modifying its underlying architecture. The new concept of
microservices fits well with our needs, and has been successfully used to implement the use case of the certified multimedia statement. The lack however of microservices off the shelf, leads us to analyze a new problematics related to microservices deployment. In addition of the SaaS model which may solve this issue by providing a remote execution of microservices, we identify a new approach authorizing local execution of microservices in the user environment and we addressed several important points concerning this new approach (security, delegation of access and business model). The introduced deployment architecture allowing local execution of microservices at the user environment raises new interesting issues. We need to prove that our architecture is strong enough to counter at least the most known attacks, hence we need to perform some pentests on the platform and evaluate the impacts on the security and the privacy. A compromised microservice can be an interesting attack vector. The trust and identity problems related to microservices should also be investigated. The identification and authentication of microservices appears by the way as an important issue. We need also a mechanism to define the level of trust that a user can have in a given microservice especially when this one has to manage private and personal informations of the user. ACKNOWLEDGMENT This work has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 645342, project reTHINK. R EFERENCES [1] E. Rescorla, “WebRTC Security Architecture,” Internet Engineering Task Force, 2015. [2] S. Kremer, “Formal analysis of optimistic fair exchange protocols,” PhD. Universit´e Libre de Bruxelles Facult´e des Sciences, 2004. [3] N. Asokan, V. Shoup, and M. Waidner, “Asynchronous protocols for optimistic fair exchange,” in Security and Privacy 1998 IEEE Symposium on Security and Privacy, Oakland, CA, USA, May 3-6, 1998, Proceedings, 1998, pp. 86–99. [4] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” RFC 3161 (Proposed Standard), Internet Engineering Task Force, Aug. 2001, updated by RFC 5816. [5] C. Jennings, T. Hardie, and M. Westerlund, “Real-time communications for the web,” IEEE Communications Magazine, vol. 51, no. 4, pp. 20–26, 2013. [6] A. Sergiienko, WebRTC Blueprints. Packt Publishing Ltd, 2014. [7] T.Koskinen, P.Ihantola, and V.Karavirta, “Quality of wordpress plug-ins: An overview of security and user ratings,” in International Conference on Privacy, Security, Risk and Trust, PASSAT. IEEE, 2012, pp. 834–837.
[8] L.Yu, L.Zhiqiao, and C.Xiang, “POSTER: study of software plugin-based malware,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, 2014, pp. 1463–1465. [9] J.Walden, M.Doyle, R.Lenhof, and A. J.Murray, “Impact of plugins on the security of web applications,” in Proceedings of the 6th International Workshop on Security Measurements and Metrics. ACM, 2010. [10] H. M. L. R. M.Villamizar, O.Garcs and S.Gil, “Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud,” in Computing Colombian Conference (10CCC), 2015 10th. IEEE, 2015, pp. 583–590. [11] S. Newman, Building Microservices. O’Reilly Media, February 2015. [12] P.K.Chouhan, F.Yao, and S.Sezer, “Software as a service: Understanding security issues,” in Science and Information Conference (SAI), 2015. IEEE, 2015, pp. 162–170. [13] I.T.Javed and all, “Global identity and reachability framework for interoperable p2p communication services,” in 19th International ICIN Conference - Paris, 2016, pp. 59–66. [14] E. Rescorla, “Security Considerations for WebRTC,” Internet Engineering Task Force, 2015. [15] A. Barth, “The Web Origin Concept,” RFC 6454 (Proposed Standard), Internet Engineering Task Force, Dec. 2011. [16] D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749 (Proposed Standard), Internet Engineering Task Force, Oct. 2012. [17] B.Deeter and R.Jung, “Software as a service pricing strategies,” 2013.
