Security Considerations

The PTV Drive&Arrive needs some data to calculate a good Estimated Time of Arrival (ETA). There are several data sources involved, including positioning information of the truck. But there are also other aspects of security, e.g. security of the tour information, security of the process etc. . In addition, the cloud based PTV Drive&Arrive running in Microsoft Azure may be a point to consider when thinking about security.

Process Security

One of the key features ofPTV Drive&Arrive is the simple solution to the "Pairing" problem. This is to enable several stakeholders of a supply chain to communicate about the same tour, e.g. for being notified about ETA violations. In the process of using and managing the information around the "Pairing" process, there are several security touch points:

• Acquiring a token - there is no such thing as registration for PTV Drive&Arrive. A customer acquires a so called "token". The token is an alphanumerical string with 25 characters. The token gives the owner the permission to save a tour for ETA monitoring in PTV Drive&Arrive. Buying a token is done outside PTV Drive&Arrive and PTV Drive&Arrive is only notified about the existence of a token and its parameters. There is no link to a certain customer with data as addresses or even account information. So, data are anonymous at some point.

• Saving a tour - given a token, one has the permission to save a tour for ETA monitoring. There is no additional registration necessary for PTV Drive&Arrive. The API does not require authentication, e.g. on HTTP level. The only credential to provide is the token. Therefore, we cannot see who is sending a token and mix that information up with a authentication/authorisation information. So, the owner of the token has the responsibility to keep the token secret and use it for saving tours only. By the way: the token is send to PTV Drive&Arrive (as an URL parameter), so it may become visible in internet traffic or proxies.

• Handling SCEMIDs - after storing a tour, you get back the SCEMIDs. Every tour has one or more stops. When saving a tour, PTV Drive&Arrive assigns a SCEMID to the tour itself and then to every stop in the tour. These SCEMIDs are crucial for further handling of PTV Drive&Arrive data and API. The owner of the tour gets back the SCEMIDs and decides how to distribute them and to what people / supply chain entities to distribute to.

• Using SCEMIDs - most of the PTV Drive&Arrive API can be used with the SCEMID. Everybody who has one or more SCEMIDs can use the API for free, e.g. for subscribing / unsubscribing to ETA notifications or for sending events to the API. There is no authentication or authorisation required, i.e. that everybody who has a SCEMID can use and benefit from PTV Drive&Arrive without special registration. This approach will help to build a large ecosystem of third-party applications around PTV Drive&Arrive and to enable a lot of people to join the PTV Drive&Arrive network. The larger the network the more benefit it will have.

Technical Security

Technical security is driven by the fact that PTV Drive&Arrive is cloud based. There are several aspects to consider when thinking about security:

• Microsoft^® Azure^TM - Microsoft^® Azure^TM is the cloud infrastructure of Microsoft^®. Microsoft^® guarantees a wide range of compliance rules.

• SSL / HTTPS - network traffic is encrypted by SSL, i.e. we use HTTPS for communication only. The certificate is a wildcard certificate for *.cloud.ptvgroup.com which is also used for PTV xServer internet.

• Client certificates - client certificates are not supported at the moment.

• Tokens or SCEMIDs - tokens have no inherent semantics, i.e. they are codes only with no information encrypted directly in there string. SCEMIDs have an internal ID encrypted which can be guessed from outside PTV Drive&Arrive. Both the token as well as the SCEMID are random strings. The length of the token is 25 characters long, i.e. we have a number of 36^25 possible combinations. SCEMIDs are ten characters long, so we have 35^10 possible combinations.

• Component endpoints - The PTV Drive&Arrive is - from an architectural point of view - splitted into several components. These components can be scaled and operated independently from each other and are loosly coupled over queues. The only externally visible endpoint is the API. The API includes several security relevant processing, e.g. large variety of validation for incoming JSON requests, a tranformation of JSON data to internal transfer objects, etc. . The de-coupled asynchronous architecture does not allow a potential attacker to get immediate feedback on his attacks in order to adjust the attack. The API refuses a request immediately or accepts a requests. If the data is ignored afterwards due to any reason, the attacker may not be informed about that.

• SQL injection - typical SQL injection issues may not arise due to the facts described above and because we use a NoSQL database.

Data Security

PTV Drive&Arrive needs several data sources in order to provide our customers with the best ETA calculation. The data sources

• Customer data - Customer data, e.g. concerning the token, is not stored in the cloud. Neither for addresses, nor for accouting information which is needed for payment and billing processes

• Tour information - Tour information and stop information, e.g. the tour journal which is readable for token owners only, are not bound to any customer specific data. Even if one would guess a SCEMID, she could not read any person-related information about the stop and could only subscribe / unsubscribe to ETA notifications. To be honest, if one would send bad information via events to that SCEMID, the PTV Drive&Arrive may misbehave. Although we have considered such things in the application logic, a large set of bad information may lead to bad results.

• Driver information - when storing a tour in PTV Drive&Arrive, we do not have any real life information about the driver or the truck. Concerning the truck, the customer specifies an abstract vehicle profile only. This vehicle profile is pre-defined and used by all customers. It is describing physical attributes of the truck as well as its standard behavior as speed on different network classes. So, we do not store any truck specific information as the licence plate that may be critical to security. <br/>Concerning the driver, we do not need or save the name of the driver. We only ask for rest and break times in an abstract way.

• Incoming external events - there may be a lot of incoming external events, e.g. positioning information. This information is used for ETA calculation and is stored in a tour journal log to be able to explain the behavior of the PTV Drive&Arrive. One of the "event features" will be a flag which can be set in the sending application. This flag defines whether the sender of the positioning information allows the tour journal owner (which is the token owner) to see the position or not. It is not affecting storage of that information and usage for ETA calculation.

• General persistance layer / database - we use a NoSQL database working on Binary JSON level.Most of the data is structured in a way which is not transparent of the user.

Security aspects of PTV Drive&Arrive

How we ensure nobody else has access to a token

• The complete communication is encrypted via HTTPS.

• We cannot ensure that somebody steals token on client side. There is no second PIN necessary to secure a token belonging to the customer at the moment. There could be one PIN in future versions that is needed with the token together.

• In order to avoid personal information in PTV Drive&Arrive an external shop for buying tokens will be independent from PTV Drive&Arrive.

How we use certificates

HTTPS server have certificates. We do not use certificates on client side - Handling of client certificates is often considered as too complicated and therefore not commonly used.

How we ensure nobody else has access to sensible custom data on server side

• There should be no personal data (e.g. driver information) assigned to position data.

• Trip or position data will be secured on server side.

How we use position data only for ETA calculation

Data send in position event has a parameter visibility. Setting the parameter visibility=false will use position data only for ETA calculation and not for any other operation. Using this feature, a driver can define whether someone else can see the position or not. It is impossible to answer any questions about events with visibility=false.