Single sign-on

Single sign-on means that there is one signing in in the vehicle and that this information is transferred to the other on-board systems as well as to connected back-office systems. The signing in is a foundation for many systems such as AVL (Automatic Vehicle Location) as well as ticketing and safety related systems. The signing-on means that an individual signs into a vehicle. The signing in can then be attached to other information such as a driver duty and a vehicle duty.

General overview

Logging in is a central function. It has to work every time, and it must not take too much time or be too inconvenient. There is a lot to gain from being able to sign in to all systems with one single login, both time, money and employee satisfaction. With a pre-login, single login solution, planned data like driver ID, vehicle ID and block ID or line/trip info can be pushed out to the vehicle which is activated through a single login, which acknowledges the driver’s presence in the vehicle.  There are, however risks to consider in the choice of different login methods, which we are going to discuss in this blog post.

Overview of login systems

For many drivers today, the login situation can be quite daunting, with separate login procedures to tachograph, alcolock, ticketing, real-time system, ecodriving and radio. Maybe the vehicle travels over region borders, then you might add one or more extra ticketing systems. All this added up, can be both time consuming, frustrating and costly.

To be able to use a single login, all systems within the vehicle need to be interconnected. This prerequisites an open standard Information Technology for Public Transport (ITxPT) vehicle network.

There is quite a considerable benefit if the login procedure also looks the same throughout all platforms. The same password/codes and user name.

This brief and general walk-through of different possible solutions on how to log in, will of course not cover them all, but give an idea of different ways of thinking, and what you might want to avoid.

Tachograph

To use the tachograph card to log into the vehicle network, has its benefits, for example that the drivers are familiar with the login procedure and that the card and the solution is already in place. Only using the tachograph card without a password, is however not advisable, following the old rule of internet security; “Something you have and something you know”. Which means that if you need a physical identifier like a tachograph card, together with a password, then you are on a good level of security. To only use the card, means that anyone who finds the card, can use it. It is not safe. Here, the username used on other platforms could be exchanged for the Tachograph card identification, and then the password can be the same as on other platforms.

RFID

To use RFID technique has many of the same benefits as the Tachograph with the security level of “Something you have and something you know”, providing of course that you use a password verification together with the RFID tag or card. A tag also has the benefit of fitting on a keychain which is practical and easy to handle.

Driver Console login

With a Driver Console connected to the vehicle network, you have the possibility to use a regular login like in any computer, smartphone or tablet. This solution has the benefit of being platform neutral, which means that you can use the same login throughout all units the user encounters within their working role. What this verification method lacks is of course the double security of “Something you have and something you know”. Here, it is important that the password is not the employment number or something similar, which would be way too easy for someone to find out.

Remote login

Traffic management can log drivers in or out of vehicles, in the situation that the wrong driver is logged in, or that no driver is logged in. This is a good way to correct errors without disturbing the driver when in traffic for example.

Pre-login – Backend login

To take effect, the login must be distributed throughout the systems in the vehicle as well as to the back-office. However, this procedure could be initiated in advance, for example when the driver arrives at the depot and checks into a time managing device or checks in with a phone. Then the information could be pushed out to the bus from backoffice, about driver ID, vehicle ID and block ID or line/trip info), which onboard systems should be logged in, and other relevant information. Then when the driver enters the bus, the login is just a confirmation or correction of information already in place in the vehicle. The login is in this case pre-connected to the block or line/trip the driver, according to plan, is going to drive with a specific vehicle.

There are however obstacles to be overcome with this process. The information in the scheduling systems, like Okapi, Trapeze and Hastus is not seldom erroneous, or changed in the last minute, due to sickness or other reasons. This makes it hard to get pre-verified information from the system.

Social login

To use a solution based on google or facebook login is not common for these types of systems, since the security and handling of the login would be out of control for the company. Later on, if there is a national or international standard, with enough security and control, this might change, but as of now, this is not really an option.

Changing password

It is important with an easy and secure process of changing password. The user name might also be forgotten, therefore the password retrieval process needs to have a solution for this as well. One way is to have an email connected to the user profile, to which a password change link kan be distributed automatically, and to which the username might be sent, along with a password update link, in the case that both password and username are lost.

Same interface for all platforms and users

With a modern, open standard, Information Technology for Public Transport (ITxPT) environment, the users often encounter the same system from different angles, different platforms and in different roles. It could be a driver checking their Eco-driving status on a computer, logging into the Driver Console in the bus, or using the checklist app on an Android phone or iPhone, to ready the vehicle for service, or a workshop engineer communicating with any driver using a specific bus, through a manual fault report application. In all these cases the interface should look and feel the same. The productivity will be much higher with a system that is intuitive, easy to use and looks the same over all platforms. This is of course extra important for personnel who are either not accustomed to the system, uncomfortable with IT devices or working in a second language. There is also a benefit not to have to remember more login credentials than necessary. Therefore, a login system so general that it could be used on any device, is preferrable.

Economy

When planning for a vehicle IT system, it might not seem like a big thing for the drivers to log into more than one system or unit, but if you take into account the possible added time, the economy behind it tells you otherwise. Let’s say that the login process takes a minute, which doesn’t seem like a lot, but with five logins per day all year, you end up with 30 hours a vehicle. With a fleet of 100 vehicles that adds up to 76 forty-hour weeks. That is one and a half year of work-time wasted on the login process every year per hundred busses.

Another thing to take into account is the willingness among drivers to adapt to new equipment, new work methods and new ideas. If the employer makes an effort to ease their work day and to improve their situation, they will be more open to change, when implementing new systems and ideas.

Security

Security becomes more and more important, as the systems become increasingly competent, and handle more and more information. The regulations in connection to GDPR (General Data Protection Regulation) also mandates practices which can’t be neglected, with the risk of a fine of 4% of the company international turnover or up to 20 million Euro.  

GDPR

The intent behind GDPR is to strengthen and harmonize the protection for people within EU in regard to handling personal information. It takes full effect may 25th 2018, when it replaces national regulations. The responsibility lies heavy on the public transport operators and authorities to adhere to the regulations, not to risk a substantial fine. So what are the most important parts of the regulations?

• Security. GDPR demands a general protection against leaking sensitive personal data.
• The security demands vary in relation to workload and cost it would demand for implementing a certain solution. Therefore a general shell protection should be sufficient in many cases, although until it has been tested in court, no precedent is available.
• You also need to know exactly who can access the info.
• Positions are personal data, as is for example eco-driving grades and anything connected to this.
• To be allowed to handle and store such data, you need the permission from the employee, unless there is a law requiring data handling and storage. The above mentioned information is hardly subject to any such law, so you need to get that permission from every employee that is subject to such storage. However, tachograph data, since it is required by law to maintain for a certain time, you don’t need permission from the driver to store the information.
• If a shell protection should be considered insufficient, pseudonymisation is the next option. This process transforms personal data so it can’t be used without a key. The two major ways to achieve pseudonymisation are encryption and tokenization.

Pseudonymisation through encryption

An example  of pseudonymisation is encryption, which renders the original data unintelligible and the process cannot be reversed without access to the correct decryption key. The GDPR requires for the additional information (such as the decryption key) to be kept separately from the pseudonymised data.

Pseudonymisation through tokenization

Another example of pseudonymisation is tokenization, which is a non-mathematical approach that replaces sensitive data with non-sensitive substitutes, referred to as tokens. Tokenization does not alter the type or length of data, which means it can be processed by legacy systems. It requires much fewer computational resources to process and less storage space in databases than traditionally-encrypted data.

The pseudonymisation catch

Although the GDPR encourages the use of pseudonymisation to “reduce risks to the data subjects,” (Recital 28) pseudonymised data is still considered personal data (Recital 26) and so remains covered by the GDPR.

Practical effects of GDPR

• One thing that probably won’t be possible to do as a result of GDPR is to have a single login, only based on the tachograph card or RFID without a password.
• A tachograph or RFID key must be unique for each company to avoid the risk of someone being able to reach the system with an unauthorized card.
• You cannot use passwords possible to attain, like employment numbers or similar.
• A user has the right to get the data saved about themselves, exported in easily accessible form, to be able to for example move it to another company. What implications this rule has, if any, is difficult to overview without a precedent.
• A process to erase personal information when no longer needed, has to be in place.
• If GDPR compliance isn’t in order, it will be flagged in a 27001 audit.

ISO 27001

ISO/IEC 27001 is an information security standard. It specifies a management system intended to bring information security under management control. To be certified, an organization needs to go through an audit. The practical implication of 27001 is that the organization must work continuously with security and risk assessment.

Most organizations have a number of information security controls. However, without an Information Security Management System (ISMS), controls tend to be somewhat disorganized and disjointed. Security controls typically address certain aspects of IT specifically; leaving non-IT information assets (such as paperwork and proprietary knowledge) less protected on the whole. Moreover, business continuity planning and physical security may be managed quite independently of IT or information security while Human Resources practices may make little reference to the need to define and assign information security roles and responsibilities throughout the organization.

ISO/IEC 27001 requires that management:

• Systematically examine the organization’s information security risks, taking account of the threats, vulnerabilities, and impacts.
• Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable.
• Adopt an overarching management process to ensure that the information security controls continue to meet the organization’s information security needs on an ongoing basis.

Integration

ITxPT has defined a shared service called “Run Monitoring” for the onboard systems so that all ITxPT compliant modules can share the information about what the vehicles are expected to produce (typically a block or line/trip login). The service is one of seven services related to AVMS (Advanced Vehicle Management System). Currently the services are web services that delivers XML tagged data. MQTT (Message Queuing Telemetry Transport) has recently been added to the ITxPT specifications and most likely this output will be available via MQTT.

Next step to specify within the group is:

• Driver login (local in the vehicle)
• Over The Air protocol for both driver login and service login

The two actions above are core components that today are missing to be able to do a standardized single sign on solution.

At the ITxPT testlab system suppliers can get their implementations and devices tested and verified towards the ITxPT specifications. After approval the device can be “Labelized” with the ITxPT marking. Visit: www.itxpt.org to see the full set of specifications.

The ITxPT specifications are pre-processors of what to be added to the EN 13149-x standard.

Login distribution in Android environment

This is a brief walk-through of how a login distribution throughout an Android environment can be handled.

An Android single-point login app calls a KeyCloak-server to retrieve a token. The token (which is only valid for a certain amount of time and needs to be periodically refreshed) then resides in memory inside the Policy Manager in a controlled environment, and can later be requested by local apps who wishes to communicate with the various online services. The apps can then use that token to, automatically upon startup and in the background, sign in to the various services accessible within the Android environment without the user having to worry about logging in over and over again. Once the user logs out, the token is forgotten and apps may no longer be able to access any of the secured online services. Driver-id (for tagging) and line-data etc is stored on the vehicle communication gateway and can be accessed by various other system as required.

In case there is no internet connection, a limited login mode is entered, based purely on the entered username. This mode only allows the tagging of data for a trip, and limited access to apps, within the Android environment, which do not require a login. The same mode is also entered in case a driver’s card is used. In order to access any online services when using a driver’s card, the user also has to enter a password. Once the password is entered successfully though, the authorization data is provided to all the other apps on the platform in the same way as described above.

Disclaimer: The content of this blog post is the author’s opinion and doesn’t reflect the opinion of any other person or organisation.