[agl-discussions] Security Framework for AGL - Review IoT.bzh Proposal

Fulup Ar Foll fulup.arfoll at iot.bzh
Tue Apr 19 19:30:38 UTC 2016

@Frederico, thank you for your review. You will find here after included 
some elements of response to your comments.

On 14/04/16 09:59, Frederico Cadete wrote:
> - Scope: given AGL's rather wide target in the automotive environment [1],
>    including "Instrument Cluster" and "Telematics Systems", what is the scope
>    of this Application and Security Framework? i.e. is it foreseen to apply only
>    to IVI and end-user-visible applications or does it encompass wider scenarios
>    such as integration of lower level SW components from multiple suppliers.
>    (From the document's several references on HTML5 and QML I am guessing the
>    first one?)
As today we clearly focus on providing a solution for IVI deployment. 
Nevertheless as you noted in your comments. AGL end goal is much broader 
than IVI only. Cluster/Telematics for sure may have very different 
security constrains. Hopefully many fundamentals should remains valid. 
How to prevent a process from doing unauthorized actions is pretty 
stable what ever your end target is. At this point in time our current 
guess is that the security framework inherited from 
Meta-Intel-IOT-Security could address many security requirements not 
only for IVI but also for Cluster/Telematics Systems. On the other hand 
the application framework clearly target dynamic operations where you 
want support for install,start,stop,remove of applications. Looking to 
the level of certification that is going to be required for 
Cluster/Telematics those systems should implement less dynamic than IVI. 
As a result current tools used to configure/upgrade baseline systems 
should probably be more appropriated than the one typically used with 
end user oriented applications and services.
> - Trusted boot, installation, updates: it's nice to see this mentioned, but
>    it's not covered in the rest of the document. It is mentioned to set the
>    security scenario where the framework will run, but it's not defined by this
>    framework. Correct?
Yannick from my team is the lucky one who was designated as volunteer
to lead that issue. We target a presentation of our research during next 
automotive summit in Tokyo/July. To make very short a long story that is 
far from being fully written. On top of secure boot our intention is to 
download baseline operating system update from user untrusted space, 
then when the new version is fully received and its signature validated, 
the update mechanism signals the trusted zone that a new version is 
waiting. On next shutdown/reboot we upgrade directly the baseline 
filesystem from the trusted zone. As today we do not focus on how to 
download in small chunks the new version of the system. I do not 
envision this part as being an issue. My team focus on how to update the 
filesystem directly from the trusted zone. Obviously exchange from/to 
trusted/untrusted zones are very dependant on hardware implementation 
which does not help.
Note that this effort is loosely connected to the security and 
application framework, even if as you mentioned, is a critical part of 
global system security.

> - W3C Application Packaging: is this to be taken as an example or as the actual
>    format? Is it feasible to package native applications in such a format?
W3C-widget is a normalized package mechanism that was originally 
designed for WEB applications. Nevertheless it can transport any type of 
files including native applications. In fact if you check the samples we 
published, some of them carry binary code.
> - Binder components (slide 18): what is the difference between "App-Level" and
>    "UI Level", security-wise? What privileges does the per-application binder
>    process have over the application process itself? This is especially important
>    for the proposed "Ad-hoc" model in slide 19.
The application framework can start any type of processes. Binder is 
only a generic model for exposing securely API to UI, applications or 
services. The model used is somehow comparable to the one used in 
Android. The difference between UI level(fully untrusted) and App 
level(somehow trusted) allow you to operate UI, application and services 
with different level of security (SMACK label, Cgroup, ...). When 
running in Ad-hoc model, UI operates directly at semi-trusted level and 
you loose one level of security.
> - REST/HTML interface: this seems to be useful for remote applications and
>    web-based local applications. But for local applications, there are a few
>    system resources that are very difficult to secure with such an API without
>    incurring prohibitive performance penalties, such as:
>       - Graphics buffer, GPU access, screen
>       - Audio pipeline
>       - Filesystem access
Does REST/HTML consume too much resource? This is a classical question 
and the best answer remains: "it depends". Depending on the context and 
background people may have different and very strong opinion on the 
subject. As software architect, my position is that we should support 
both native & HTML5 UI. The mobile phone industry succeeded in doing so 
and I do not see why the automotive industry could not follow the same 
path. This being said and independently of the chosen model you still 
have to implement a strong isolation in between UI, applications and 
services. Such isolation imposes a serialisation of exchanged data as 
well as an isolation of processes.

To come back on your concern about streaming, typically when you play a 
sound you activate some audio service (ie: rygel) and the media player 
streams the audio directly onto the audio device. Same thing for
video, where UI process handles the decoration around the video, but the 
video is played directly at hardware level. Finally most of the 
activation and exchange from untrusted application to services remain 
somehow limited.

You're nevertheless right that security isolation will have a cost in 
term of performance. This being said as not one will accept a system 
without security, the question is not "how to mitigate security and 
performance ?" but "how to make the cost of required security acceptable ?".

> - APIs as JSON specifications
>    Cool. If the REST and DBUS interface can both be extracted from the same
>    spec it should greatly simplify the maintenance of those interfaces.
>    I fear this runs the risk of being yet another IDL for this domain, adding
>    to at least (at the top of my head) Franca and the RVI signals.
>    I suppose the alternatives have their demerits for this use case though,
>    and unfortunately I don't see a solution for this proliferation.
>    I just expect some work in hand-translating interfaces down the road, and
>    of course appreciate all the contributions :)
As today AGL does not require any IDL also proliferation is not really a 
concern. Our point with "JSON as spec" was that APIs specifications 
should remain independent of transport layer. In fact pure JSON might be 
too limited for spec, it especially lacks comments. While nothing as 
even be proposed, my team would be please to look at modern options like 
OpenAPI [https://openapis.org]. Chosen model should be easy to embed 
with Yocto, should not ask for rare skills, the cost of adoption should 
remain minimal and it should provide out of box tools for testing and 

Note: the binder we presented in February in Tokyo did only support 
REST. Current github version supports websocket and before the end of 
the month we should have finished DBUS integration. In our proposal 
transport layer is completely transparent to developers. Even if as 
today we transport only bare JSON messages. It looks obvious that in the 
near future we will be asked for optimisation. For example a service 
interfacing with MongoDB storage may want to exchange directly in BJSON 
to boost operations. Moving from one transport to an other one, or from 
one flavour of JSON the other should be fully transparent to developers 
or applications and selectable dynamically at runtime.

> Best regards,
> Frederico
> Frederico Cadete
> R&D Software Engineer
> VIT Software Development

More information about the automotive-discussions mailing list