Use of SSL Profiles in WSO2 ESB

SSL profiles in WSO2 ESB allows you to use different trust stores/ key stores for different hosts. For example you will have couple of hosts that requires 1-way SSL (SSL-client is not verified by the server. Only server is verified by the client.) and another host requiring 2-way SSL (Mutual SSL - it is a certificate based authentication where two parties [client and server] authenticate each other by verifying digital certificates. So in simple terms both parties are assured of other's identity.).

In here I have given an example where ESB acting as the server. 1-way SSL requires only key store in it's configuration. For mutual SSL you need to configure both trust store and the key store. In ESB we can have 2 different SSL profiles to support the above mentioned scenario. One profile for hosts requiring only 1-way SSL and another profile for the host requiring mutual SSL.

How to configure SSL profiles in WSO2 ESB.

Open  <ESB_HOME>/repository/conf/Axis2/axis2.xml. Edit <transportReceiver> configurations as follows. (If ESB is acting as the client you have to edit <transportSender> configurations to add customSSLProfiles.)

<transportReceiver name="multi-https" class="org.apache.synapse.transport.nhttp.HttpCoreNIOMultiSSLListener">

        <parameter name="port">8343</parameter>

        <parameter name="non-blocking">true</parameter>

        <parameter name="SSLProfiles">

            <profile>

                <bindAddress>localhost:9445, localhost:9446</bindAddress>

                <KeyStore>

                    <Location>/path/to/keystore1.p12</Location>

                    <Type>PKCS12</Type>

                    <Password>key1</Password>

                    <KeyPassword>key1</KeyPassword>

                </KeyStore>

            </profile>

           <profile>

                <bindAddress>localhost:9455</bindAddress>

                <KeyStore>

                    <Location>/path/to/keystore2.p12</Location>

                    <Type>JKS</Type>

                    <Password>test</Password>

                    <KeyPassword>test</KeyPassword>

                </KeyStore>

                <TrustStore>

                    <Location>/path/to/trustStore2.jks</Location>

                    <Type>JKS</Type>

                    <Password>test</Password>

                </TrustStore>

                <SSLVerifyClient>require</SSLVerifyClient>

            </profile>

        </parameter>

</transportReceiver>

 As you can see 1st profile contains only key store. And it has 2 bind addresses. That means hosts running on localhost:9445 and localhost:9446 will use this profile for their SSL authentication.

2nd profile has both key store and trust store configurations. And also it has <SSLVerifyClient>require</SSLVerifyClient> parameter added to the configuration. That is used to enable mutual SSL. This profile will be used for host running on 9445 port. Like wise we can have multiple SSL profiles for different hosts and also we can have same profile for different hosts. This is useful when you have many proxy services or APIs running on your WSO2 ESB.

Configure ciphers in WSO2 Servers to establish secure connections.

Cipher suites are encryption algorithms which are used to establish secure communication between host and the client. However cipher suites can be classified in to different categories based on the level of security they provide. Some ciphers are capable of providing better security compared to others. So sometimes you will need to customize the ciphers that your server should support in order to have a better secure connection.

These supported ciphers can be given to any wso2 server. To test the supported ciphers, first download TestSSLServer.jar from here http://www.bolet.org/TestSSLServer/TestSSLServer.jar. It is a command line tool which contacts a SSL/TLS server and provide information on supported protocols and supported cipher suites. 

Then start a WSO2 server and normally server will start from port 9443.

Go to TestSSLServer.jar location from command line and list supported protocols and ciphers using this command.
java -jar TestSSLServer.jar localhost 9443

Then you can see a list like this.

Then again shut down the server and go to <product-home>/repository/conf/tomcat folder and open catalina-server.xml. Find the relevant connector configuration with SSL/TLS configurations. Add another field as ciphers and give preferred cipher list in a comma separated manner.

EX:

<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" 

port="9443"  

bindOnInit="false" 

sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"  

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"

Here I have given only two ciphers.

Then again start the server and list supported protocols. There you can see only the given ciphers are supported by the server.

Server will accept requests from clients supporting these given protocols. If client does not support given sslEnabledProtocols or ciphers, server will not establish a secure client/server connection.

Guidelines for OBD Reader Android Application Development

OBD adapter is an electronic device that allows a computer to access the vehicle network through its ECU (Engine Control Unit). OBD2 adapter can be plugged into the OBD2 ports (Data Link Connector (DLC)) in a vehicle. Data coming from the ECU can be retrieved from an android application via Bluetooth connection. OBD2 provides real time data.

Data flows both ways through OBD2 to and from the ECU. This will be the flow of data

1.  Mobile application sends request to the OBD adapter via Bluetooth interface (AT commands).
2. OBD2 adapter receives the request.
3. OBD2 retransmits the request to the ECU on one of the OBD protocols
4. ECU responds back with the data to OBD2.
5. OBD2 sends data to the mobile application.

A protocol is used for the communication between OBD device and android application. It is text based polling type protocol. That means you should send commands as requests in order to get a response. 

OBDSim

Since it is not possible always to test OBD2 related applications in a real environment with a vehicle there are existing application which has the capability to simulate a vehicle with an OBD device plugged in.

OBDSim is one such simulator which we have used to test our mobile application. This is a cross platform and works on Windows/ Linux software platforms. Similar to ELM327 OBD2 adapter this also works on AT commands which are used to configure an ELM327.

Installing OBDSim

You can download it from this link http://icculus.org/obdgpslogger/.

Useful links to set up OBDSim

1. http://stackoverflow.com/questions/13164150/obd2-elm327-bluetooth-simulator?lq=1
2.  http://stackoverflow.com/questions/21957505/connect-obdsim-to-torque-on-windows-through-bluetooth
3. http://stackoverflow.com/questions/25720469/connect-obdsim-to-torqueandroid-app-ubuntu/25763606#25763606

After installing and running the OBDSim we can manually change the parameters and test our application.

Developing Android Application

Application should be capable of performing following functionalities.

• Connect to OBD device through its Bluetooth interface.

• Initialize OBD adapter with AT commands.

o   AT SP 0 - This is to set the protocol to “AUTO”. That means we want the interface to automatically detect the protocol when we send the first OBD request. If it is successful reply will be “OK”.

o   AT DP - To verify the protocol (Display Protocol). Reply – “AUTO

•      Continuously retrieve data from OBD adapter.

We have to use OBD-II Parameter IDs (On-Board Diagnostics Parameter IDs - PIDs) in order to communicate with the vehicle. Those individual PIDs provide some specific information on vehicular data. 

OBD-II PIDs (On-Board Diagnostics Parameter IDs) are codes used to request data from a vehicle. There is a standard set of PIDs which is defined by SAE standard J/1979. Other than that, manufacturers define their own PIDs.

Process of communication through PIDs.

1.  Mobile application sends PID s as requests to the OBD2 adapter.

2. OBD2 device sends it to the vehicle’s controller area network (CAN).

3.  A device on the bus recognizes the PID as one it is responsible for, and reports the  value for that PID to the bus.
4. OBD2 reads the response and send it back to the mobile application.

 Example PID s that are sent to get speed and RPM.

           o   010C – Get RPM. Example reply – “41 0C 0F A0”. The reply contains two bytes that identify it as a response to Mode 1, PID 0C request (41 0C), and two more bytes with the encoded RPM value (1/4 RPM per bit). To get the actual RPM value, convert the hex number to decimal, and divide it by four: 

                                                     0x0FA = 4000

                                                     4000/4 = 1000 rpm

o   010D – Get vehicle speed.  Reply – 41 0D FF. To get the speed have to convert this to decimal.

Crowdsourced traffic data analysis and visualizing using WSO2 CEP.

Introduction

Aim was to develop a mobile application and a website to get reliable traffic data in certain areas. GPS data received from smart phones of users was analyzed via CEP. When the users log into the android application their GPS data was sent to the CEP. From the data received, it was possible identify the location and moving speeds of users. Analyzing the traffic condition was done inside CEP. After analyzing, crowd sourced data about traffic is displayed on a map. 

Usage of geo-fencing and level of service to calculate traffic

Geo fencing is a feature that can be used in a software program to define the geometrical boundaries. In our project this technology was used to segment the road. Geo-fencing custom extension in WSO2 CEP is used to define the boundaries and filter vehicular data. When CEP receives an event, its coordinates are checked against the defined boundaries to check whether it is inside or outside, using OSGeo Geo Tools library [1].

We used the method Average Travel Speed (ATS) to calculate traffic level of service.

ATS = Distance / average time of vehicles

One execution plan includes all the required processes to calculate the traffic status of a particular road segment. 

User’s imei number, longitude, latitude values were passed in to the execution plan from an event stream.

In the execution plan two polygons in one junction were defined using longitude and latitude coordinates of the road segments. When CEP receives an event check whether it was within the range of defined polygons. If they were within those polygons events were sent to two different streams based on the polygon which they belong to.

Siddhi Query

from nospeedstream[geo:iswithin(longitude,latitude,"{'type':'Polygon','coordinates':[[[79.84941602,6.91021645],[79.85038161,6.91049338],[79.85070348,6.90979042],[79.84948039,6.90930048],[79.84941602,6.91021645]]]}")==true]

select imei , longitude,latitude,timemili

insert into filteredPoly1;

Then the entering time stamps of each individual vehicle for first polygon and the second polygon were recorded separately. And those timestamps and imei number of vehicles were passed to another stream.

from filteredPoly1#window.unique(imei) as p1 join filteredPoly2#window.unique(imei) as p2

on p1.imei == p2.imei

select p1.imei as imei, p1.timemili as timemili1,p2.timemili as timemili2

insert into joinedpolydata;

from joinedpolydata#window.firstUnique(imei) as p1

select * insert into uniquejoinedpolydata;

After that, time difference of each vehicle was calculated. If it becomes negative that indicates the vehicle is travelling to the opposite direction. From that we can separate the vehicles according to their travelling directions. Vehicles having positive time differences were sent to the ‘positivetimeDiffStream’ and negative ones were sent to the ‘negativetimeDiffStream’.

from uniquejoinedpolydata

select imei, (timemili2-timemili1) as timediffmili

insert into timeDiffStream;

from timeDiffStream[timediffmili>0]

select imei,timediffmili as postimediffmili

insert into positivetimeDiffStream;

from timeDiffStream[timediffmili<0]

select imei,(-1*timediffmili) as negtimediffmili

insert into negativetimeDiffStream;

Then the average time difference of all the vehicles belonging to that road segment within a particular time period was calculated for both directions.

from positivetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(postimediffmili) as free_flow_speed_d1

insert into avgtimediffmilistream;

from negativetimeDiffStream#window.time(30 sec)

select "Kolpity" as junc_id,avg(negtimediffmili) as free_flow_speed_D2

insert into avgtimediffmilistreamneg;

Then the average vehicle speeds of each direction were calculated and the distance of road segment was divided by it to calculate the average speed of each direction.

from avgtimediffmilistream

select junc_id, ((1000/free_flow_speed_d1)*5/18) as free_flow_speed_d1

insert into avgspeedpositive;

from avgtimediffmilistreamneg

select junc_id, ((1000/free_flow_speed_D2)*5/18) as free_flow_speed_D2

insert into avgspeednegative;

This average speed data was then sent to a mysql database through a mysql output adapter in CEP [2].

From this average speed, we can define the traffic level of each direction in application level.

API

A REST API was introduced for outside apps to can call and get data from the system. The API was written using WSO2 Jaggery. It is possible to receive the following metrics through the REST API.

Get all traffic data

Sample request:

GET /apis/traffic

Sample response

Get traffic for specific junction

Sample request:

GET /apis/traffic?junc_id=kolpity

                   

junc_id : We can get traffic status in a particular junction. 

Sample Response

All traffic(only traffic info)

Sample request:

GET/apis/traffic?trafficonly=true

Sample response:

Traffic for specific junction (only traffic info)

Sample request:

GET/apis/traffic?junc_id=kolpity&trafficonly=true

Sample response

Finally, traffic condition will be visualized on a google map as in the picture shown below. Red marks are for visualizing high traffic areas and green marks are used to visualize low traffic areas.