Re: What I am missing

Perfect is the enemy of good. I understand the principles and problems
of cryptography. And in the same way we rely on TLS and its security
model today we would be able to put some trust into the same
architecture for signing script.

FYI: Here's how signing works for java applets: You need to get a
software signing key from a CA who will do some form of verification in
regard to your organization. You use that key to sign you code package.

Will this forever prevent the spread of malware ? Of course not. Yes -
you can distribute malware if you get somebodies signing key into your
possession or even buy a signature key and sign your malware yourself.
But as long as the user is made aware of the fact that the code has the
permission to access the file system, he can decide for himself if he
wants to allow that or not. Much in the same way that he decides to
download a possibly malicious peace of software today.  There will never
be absolute security - especially not for users who give a damn about
what they are doing. Should that prevent us from continuing the
evolution of the web environment? We might as well kill ourselves
because we are afraid to die ;)

One last thing: Most Android malware was spread on systems, where owners
disabled the security of the system .. eg by rooting the devices.

Michaela

> Suppose you get a piece of signed content, over whatever way it was
> delivered. Suppose also that this content you got has the ability to
> read all your private data, or reformat your machine. So it's
> basically about trust. You need to establish a secure channel of
> communication to obtain a public key that matches a signature, in such
> a way that an attackers attempt to self-sign malicious content is
> foiled. And you need to have a way to discover (after having
> established that the entity is the one who was intended and that the
> signature is correct), that you indeed trust that entity.
>
> These are two very old problems in cryptography, and they cannot be
> solved by cryptography. There are various approaches to this problem
> in use today:
>
>   * TLS and its web of trust: The basic idea being that there is a
>     hierarchy of signatories. It works like this. An entity provides a
>     certificate for the connection, signing it with their private key.
>     Since you cannot establish a connection without a public key that
>     matches the private key, verifying the certificate is easy. This
>     entity in turn, refers to another entity which provided the
>     signature for that private key. They refer to another one, and so
>     forth, until you arrive at the root. You implicitly trust root.
>     This works, but it has some flaws. At the edge of the web, people
>     are not allowed to self-sign, so they obtain their (pricey) key
>     from the next tier up. But the next tier up can't go and bother
>     the next tier up everytime they need to provide a new set of keys
>     to the edge. So they get blanket permission to self-sign, implying
>     that it's possible for the next tier up to establish and maintain
>     a trust relationship to them. As is easily demonstratable, this
>     can, and often does, go wrong, where some CA gets compromised.
>     This is always bad news to whomever obtained a certificate from
>     them, because now a malicious party can pass themselves off as them.
>   * App-stores and trust royalty: This is really easy to describe, the
>     app store you obtain something from signs the content, and you
>     trust the app-store, and therefore you trust the content. This
>     can, and often does go wrong, as android/iOS malware amply
>     demonstrates.
>
> TSL cannot work perfectly, because it is built on implied trust along
> the chain, and this can get compromised. App-stores cannot work
> perfectly because the ability to review content is quickly exceeded by
> the flood of content. Even if app-stores where provided with the full
> source, they would have no time to perform a proper review, and so
> time and time again malware slips trough the net.
>
> You can have a technical solution for signing, and you still haven't
> solved any bit of how to trust a piece of content. About the only way
> that'd be remotely feasible is if you piggyback on an existing
> implementation of a trust mechanism/transport security layer, to
> deliver the signature. For instance, many websites that allow you to
> d/l an executable provide you with a checksum of the content. The idea
> being that if the page is served up over TLS, then you've established
> that the checksum is delivered by the entity, which is also supposed
> to deliver the content. However, this has a hidden trust model that
> established trust without a technical solution. It means a user
> assumes he trusts that website, because he arrived there on his own
> volition. The same cannot be said about side-channel delivered pieces
> of content that composit into a larger whole (like signed scripts).
> For instance, assume you'd have a script file (like say the twitter
> API). Twitter signs that file. Let's assume there's some mechanism to
> verify that twitter as identified by their domain name, and as trusted
> over their TLS can then be contacted to provide their public key, so
> you can verify the signature. How do you know you can trust twitter?
> You haven't visited their website, you might not know who they are,
> for you, they're just one of dozens of entities which produced the
> content, which combines to a whole. Would you have to visit each
> signatories TLS presence to establish that you are satisfied they're
> trustworthy?