[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 ,
> 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
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 Cadete
> R&D Software Engineer
> VIT Software Development
More information about the automotive-discussions