[Dev] Cynara

Jussi Laako jussi.laako at linux.intel.com
Fri Apr 11 12:34:42 GMT 2014

On 11.4.2014 12:53, Carsten Haitzler wrote:
> do you use linux? X11? do you even intend to use wayland?

Yes, but I also know how to modify it and not let X11 access certain 
input devices. I don't have any plans for wayland, maybe once it matures.

> so you throw out all the security giving unabridged access to this app.
> so youi fully trust this app to not just blast over /dev/mem or
> /dev/kmem or add backdoors into your kernel or libc, but you can't trust
> a display server that is shipped with the os (kernel and more)? i smell
> a bit of a double standard here.

Of course! Display server is NIH! And you just said it's malicious, I 
don't trust purposefully malicious applications.

I want to decide component by component. I switched over to Debian 
because I don't trust systemd (it screwed up two of my openSUSE 

> and all that input goes through the display server. x11 supports xinput
> to allow clients to see things.. like multitouch devices and mroe
> advanced devices. one of these days try:
>    xinput list

I know, that's besides the point. But that's one of the X11 security flaws.

> but 99% of peolpe don't. what you do in your locale area is not what 99%
> of users do.

1% of the world population is A LOT of people. I'm one of the people who 
are interested on products like:

> because you replied to my mail that mentioend that weston (wayland
> display server) would have access to pim data regardless of security
> measures as long as some app could read the data and display it (which
> there will be) and/or write to it. weston was sepcifically mentioned in
> the original mail.

It was mentioned as an example, but I think the point behind the message 
was to refer to any OS services running on the system.

> then you'll have to make your own os and display system as that is not
> how the ones we have work.

More like make my own distro, but that's what I'm already doing using 
Yocto. I get quite many things I want with Qt Embedded.

> i deal with production issues in making products regularly and have done
> so for many years. a few ms of latency is a production issue BUG that
> halts the release of a product. that is how important latency and
> performance is. every level of abstraction costs more power and people
> spend weeks tyring to save a few percent on power budgets in tests, and
> that without these, products again don't ship.

Well, Android and WP both have practically virtualization through the 
runtime. For example UML is just another way.

> you indicated this at many occasions. that is the whole topic of this
> thread. i've never digressed from discussing the display server, and

No, topic of the thread is Cynara and access control of native OS 
services. Display server was just mentioned as one example of such.

> for a smart card, the data is presented to userspace, it is not
> magically transmitted over the internet

But for that userspace as well it is just encrypted blob. It is 
understandable only to the smart card internals and to the service on 
the other edge of internet.

> you have created a very specific case where the modem tsalks directly to
> the smart card and the modem provides networking. in the general case of
> a smart card, you would need to read the data and send it via a tcp etc.
> socket via whatever networking means your os supports, and the
> routing/destination would be handled by the app.

It doesn't matter for the case if it's modem or if the modem is just 
software running on APE, or if it's something else in normal user space 
Linux. Modem is just a piece of software like everything else on the 
system. With LTE it is more or less just an IP data pipe.


You cannot forge this challenge-response handshake unless you can 
extract the key from SIM card.

In the original SSO implementation we used SIM's authentication engine 
to generate data encryption keys, this handshake doesn't go through the 
display server. And display server nor the PIN code application doesn't 
have access to the SIM API, it can only respond to the PIN request WHEN 
initiated by the SIM card. We just used our own N pieces of our own RAND 
and the resulting SRES' was basis for the encryption key.

RAND-SRES handshake is between UI-less daemon and the SIM card. PIN code 
GUI is completely separate from this process. Even if your display 
manager knows PIN code, it also need to know RAND in order to construct 
same key.

There is also EAP-SIM for WLAN and such, see:

More information about the Dev mailing list