09.00 | - Welcome, logistics (e.g. IT) and agenda review
- Setting up IT related stuff, getting everyone connected
- Announcement: GENIVI Spring AMM will take place on May 12-14 in Leipzig, Germany. We will have AASIG face to face meeting(s) there
| TODO |
09:20 | Agenda Review - Philippe: reminds the objective of the meeting which is to agree on a couple of design scenarios and move to detailed design and implementation, target is to have PoCs available at the end of Q2 and be able to contact Google
- Gunnar: Contacting Google -> we need to prepare before the time window closes
- Going though the agenda, topic by topic so that everyone is in-sync
|
|
09:30 | Roundtable - Alexander: BMW, connectivity, now looking into boardnet abstraction and how we can use it on different platform
- Gunnar: Genivi project, development/technical lead of Genivi
- Piotr: Tieto, AA for 3 years, audio routing, helping with Genivi
- Stefan: Tieto, AA for 8 years, mobile, embedded, architecture
- Philippe: Genivi 10 years, Autosar in parallel, working with German OEMs & tier1, before was managing a SW consulting company working with Continental in particular, Telecom before that and Aerospace
- Bartosz: Tieto, wroslaw, 8+ experience with Android, multimedia domain
- Nadim: esolutions, elektrobit, Mobis, SW developer, how Mobis can contribute
- Justin: hardware engineer, connectivity, audio, how Mobis can contribute
- Kevin: CTO high mobility, data model of the car, and other topics, see where Genivi is going
- Gururaja: Bosch, 6 years with Genivi, connectivity, Android development
- SKYPE: Johan: Mitsubishi electric tier1, 6 years, Genivi quite new, but would like to get back
- Sachin: Mercedes Benz Research North America
|
|
| Vehicle HAL Security design |
|
09:45-10:45 | Access control and permissions in Android (Stefan) |
|
| - Stefan shows slide deck : Build connection VSS to Android permissions model.pdf
- Stefan shows also :
- custom permissions: only one is available, it is CAR_VENDOR_EXTENSION, this is a problem
- we need to invent our own version of this extension for additional permissions we might need
- Android have already a group of permissions available via API (manifest file for examples)
How to verify permissions - For verifying the permissions, there are different strategies and security concepts
- Even for new applications, we can assess how harmful an application is
- Gunnar: question on the key management and the signature verification process
- Piotr: the playstore is considered as a trusted source of applications
- Stefan: shows the verification process as set up by Google, link: https://source.android.com/security/apksigning/v2
- OEMs need to have a secret key service management inside their process in order to support the permission verification
- the package can be signed with the platform key and released to GooglePlay
- there will be for instance different instantiations of the same code with different signing keys for the different vendors (OEMs) who want to deploy the same app
- currently there is no shared signing key among OEMs
- when Stefan says GooglePlay, this is GooglePay in GAS
- Guru: my original thought was that both the app developer and the OEM should approve the deployment of an app with their own key
- Stefan: this is not possible, there is only one key
- Gunnar: can an App be signed by 2 different keys ? The system would check the signature of both keys
- Stefan: Samsung, Sony do this, they use additional APIs for this purpose
- Guru: This restricts how third parties can create application for our systems
- Sachin: what do you mean ?
- Stefan: We can have our own version of stores
- Gunnar: this needs more thought, the idea is to have two signing keys, developer that I made this, system that we agree to this.
- Stefan: But it's not possible
- Alex: let us assume every OEM has its own playstore, the key is developer key, but the OEM would add it or not
- Side load an application (APK download and application)
- So the model is that everything that is downloaded is already accepted by the system
- The store is not the only source of applications
- Gunnar: This is more a question about open/close system: it's for the user to accept the permissions and the OEM should not restrict or regulate them unless it is a sensitive permission. We don't need to sign it from the OEM
- We already showed that the properties are available and some not (protection level), a propert can be: normal, dangerous (needs to be asked, user should agree), signed, privileged
- Sachin: each display will have their permissions, for OEM how can we configure these displays
- This might be treated in the next presentation by Piotr
- Gunnar: the normal model is that the system does verify the signature
- Each developer sign with their keys and put them on the app store
- The system checks if the signature is valid and the key format is correct
- There is no cross checking (like https and playstore)
- Playstore is only certifying that the application was downloaded using the playstore (and not a side download).
- Gunnar: We need to check the open/semi-open model, and understand how we will manage it from technical point of view.
- Analyzing the need and the solutions
- The solutions would be too much for this group
- Probably these discussions are being done already between single OEM and Google but not with GENIVI
- Or we need to have our own service.
- Side note: The Android deficiencies come from the history of Android, from phone to car, there are gaps
Next steps - Gunnar. there is some work to figure out the different models
- Sachin: Google has decided beforehand for instance that controlling the HVAC is only possible for an App signed with the platform key
- Sachin: in a car we will have multiple displays with different permissions because displays show different things
- Piotr: I will make a proposition for this because AFAIK this is not supported by Google
|
|
10:30-10:45 | Break |
|
10:45-11:30 | External service approach - how to use Adaptive AUTOSAR Identity & Access Management (IAM) (Alexander) |
|
| - Alexander had a sync with Giovanni Vergine & Stefan Wysocki on Adaptive Autosar IAM prior to the F2F but we realized there are many open issues we need to look at
- First we need a solution for accessing or exposing the data in the vehicle.
- For example: Ambient light, you can change the color, brightness etc. During development, the application developer is directly communicating with the ECU developer to talk about the colors etc. But this does not scale.
- We need a system that can handle data like what are the colors enums etc
- Question is: how to authorize this and how can we ensure this communication.
- Idea: Authentication service, Data service.
- Data service would request the data
- Authentication would check if this App can get this data and give a token to the data service
- The data service is then using the token to get data
- Alex: yet another example
- parking assistance data cannot be abstracted using VSS because there are too many states,
- Alex: explains why we need some kind of abstractions of vehicle data to share knowledge with developers who are spread geographically (they cannot share their knowledge of the car like if they were sitting in the same room)
- Alex: would like to have a specific service offered by the platform to get access to the vehicle data
- Alex: Autosar does not seem to be so extensible
- Alex; we will need to generate tokens to enable the access to applications (token valid for an hour or one day or...)
- Alex: in VSS we have leaves which are the data, we will have also groups, we do not know which granularity should be shown at the application manifest level
- Android is activity based. If we make the data service in the framework does it have an advantage ?
- Advantages
- We can control better, for example not to forward the request to the data service if the authentication service stopped it
- Also we would have one way to access the data
- Disadvantages
- Bottleneck for the applications always passing through the framework
- Data server app authentication process have been added to the architectural concepts diagrams, look at AuthenticationMethods
- We need to think about the idea, what is better - service layer or application layer ?
|
|
11:30-12:30 | Users vs. permissions - presentation of the zone concept in Android 10 (Piotr) |
|
| - Piotr shows this Users and permissions.pptx
- overview of Android account types (taken from Google documentation)
- Piotr explains how a user can be identified, how to recognize user
- Primary, secondary, guest currently available on android
- discussion on how to check app/user permission, connection to what was discussed earlier
- In Android Automotive now, we have the following situation
- Headless system user: main services, owner of services, etc.
- Secondary user: driver etc.
- First example - audio
- as a rear user I'd like to play my audio on rear headphones
- the display in the rear or audio in the rear are now solved by using a different user id
- HAL is not aware of the user: that's the problem
- Same solution as above, application will ask the authorization service for a token and then the application can use this token in order to access graphql (i.e. the vehicle database)
- Other possibility is a content provider, this is the most common way in Android for the application layer to access data
- Main point is that there is a single point of access for example to the HAL
- One example to understand more: let us assume we have one tyre monitoring application developed by BMW
- if I log as a BMW user, I got all data (tyre temperature for instance in addition)
- if I log to the same application as a Mobis user, I do not get all data
- There might be that the dealer would like to know how many times the wheel over-heated, this is regardless of the user
- Guru: regarding users, we have a lot cases - valet, chauffeur, kids mode, etc.
- Guru: can we solve this with the VSS model or with an API created for this purpose ?
- Do we need an application that runs differently for different users ?
- Kevin: it's up to the application to show the UI according to the user
- This is also a point that the framework should not be deciding on behalf of the application what data is accessible
- Is this needed for the boardnet data?
- Do we have specific examples to show that we need a different user for the same application
- Do we need to give different permissions to different users?
- Gunnar: can we come up with such a use case ?
- Gunnar: one option is to create a specific API when you need to access very finely controlled data and not embed the access control in the VSS database
- Another example: the taxi driver's situation
- for Mercedes Benz a taxi belongs to a specific car line (i.e. a taxi has different features than a normal car)
- These users are not really the Linux users but they have their own places to store the data
- Sachin: what we want to achieve is to expose to the Android world the vehicle properties which we have been handling in the Linux-based infotainment systems so far
- Alex: can you and your wife be logged in the system at the same time?
- Sachin: the answer is no
- Sachin: the control of the display is only based on its position not on whom is using it
- Sachin: the restriction at application level does make sense
- End of long discussion on how to control access to data at the application or the service (framework) level
wrap-up (before and after lunch) - data access verification component: application permissions and user permissions need to be combined
- Letting the application decide what to do is good but not for a closed system (TBC)
- Framework needs also to have restriction
- Permission management can solve this by creating permission of groups
- Gunnar: we need UID (user identity) to be shared down to the low layers
- Discussion about what we need to solve, what is the problem to solve ?
- There are different solutions of course even with Android
|
|
12:30-13:45 | Lunch Break |
|
13:45-14 :50 | VSS layers |
|
| - Please refer to this VSS composable layers for an introduction to VSS layers concept
- Gunnar presents a short implementation of Android permissions in VSS (TODO Gunnar to provide link to example code)
- New extension Apspec that links the main signal database to the permission of each
- In the standard there are signals, attribute, sensors
- The permissions are different for different systems so the permissions files need to be independent of systems
- The idea is that we can have metadata such as Android permissions in a separate file
- Alex: coins the idea of a deployment file Apspec and have the permission "attribute" as a generic thing in the VSS layer and the "Apspecs" in the deployment data for Android Automotive
- for instance in Autosar you would have a different folder with the permission
- Gunnar: shows the implementation of VSS layers he has in mind
- The ideas are written in the file fuelsystem.appspec
- Think about generic solution
- Think about grouping
- Think about permission level
- Does write access also give read access ?
- Closer to VSS and easily parse-able
- Gunnar: we need to write some tooling to process the VSS layers
- Apspec could have no include just the entire name
- Is it better to keep the same structure?
- Opposite mapping - entity
- Nearest to the Android
- Protection level can be included
- More user friendly
- This is preferred
- There is no point of thinking of very complex scenario, because at some point we can create custom API
Wrap-up - We will investigate the following tracks
- Track #1: do not include users, just the authentication service and application talking to directly to data server, the users will be dealt with a different custom solution
- Track #2: include the users and let the application only communicate with data server from one point of entry
- For Android applications, we will have a list of permissions listed in a file, and then we have the (VSS ?) leaves listed inside each permission
Information |
|
| Vehicle HAL Security design ends |
|
14:50-15:05 | Break |
|
15:05-15:20 | Agenda re-shuffling |
|
| Vehicle HAL Technical Proposals - further refinement |
|
15:20-16:00 | Android internal service (Some signal-connecting library using VSS standard) (Stefan) |
|
| - Stefan shows this VSS to standard Vehicle HAL.pdf on the translation from VSS to VHAL properties
- Long discussion on variant III slide and content of vehicle HAL (custom HAL vs. vendor-extension)
- Discussion on various alternatives to implement things in Treble or the framework
- We don't write in HAL but in HAL extension
- We have some work to do to agree on the model before having people work on implementation
- Mapping from vehicle data to VSS and properties is needed
- Kevin: as a third party app developer, do I choose if I want a permission of Android or a VSS permission? Are there two ways of getting data?
- Yes but the Google way is key/value, with a limited API
- For instance VSS has battery status, Google does not, what happens in the future ?
- So yes there is two ways of working
- SOA or Data driven approach
- We need to define which data are cached or which data has to be directly taken
- Property value change propagation will be covered by the protocol implementation we use to communicate between the data server and the app
- If we only have get/set/subscribe we don't need an API
|
|
16:00-16:10 | Break |
|
16:10-17:05 | External services - SOME/IP (Gunnar) |
|
| - Gunnar shows the slide with Some/IP usage between the vehicle nodes (look at slide 14 Architectural proposal III (via Global SomeIP Service) of this Vehicle HAL Architectutal Architectural Design Concepts
- The idea is to mirror in the framework layer services that are outside the system,.
- This is related to connecting Android and non-Android systems
- The general connectivity concept in Autosar is the following
- there is a request, followed by a send to authentication: is this request allowed? Then the request is denied or the data are sent back
- The concept here is saying: any app will check in the database if the request is allowed or not
- But in case of external apps/db to the system, the app will only check if the system can request data but not per application
- So the system needs to implement a way to check if the application can access the data from the external app/db
- Note: The full SomeIP specs tree is available online for more reading at https://www.autosar.org/standards/foundation/ , select Release R19-11
- When we have a VSS, we can better describe or know where the data is coming from exactly
- The main problem with app directly or via socket communicating with external services is that we won't have control over them, there is no check if this app is allowed to access it
- Piotr: what about a service that does some service discovery and tries to do the request of the API ?
- Johan: cannot we put the managers in the HAL ?
- Actually we discussed it before, it's not a hardware and this is why we shouldn't officially put it in the HAL, this is not where it belongs
- But we can put it in the HAL because we can make it just to say that this is another abstraction layer
- interesting discussion on why to use SomeIP, how to aggregate data through an ad-hoc data server talking via someip to get the elementary data
|
|
17:05-17:15 | Agenda review for Day 2 - We need to change the architecture diagrams
- We need to decide what do we want to implement
- We need to name the ideas or concepts appropriately
|
|
17:15 | End of Day 1 |
|
