thank you, that explains a lot more! Am Mittwoch, 30. Juli 2014 15:09:42 UTC+2 schrieb Jeffrey Walton: > > On Wed, Jul 30, 2014 at 8:10 AM, reox <[email protected] <javascript:>> > wrote: > > okay, that explains some bits. > > i read on this site > > > https://securityledger.com/2014/07/old-apache-code-at-root-of-android-fakeid-mess/ > > > the following paragraph: > > > >> Application signatures are the basis of the Android application trust > >> model, linking specific applications with a reputable certificate > authority > >> and implicitly trusting and, which tie back to specific certificate > >> authorities and determining what permissions an application has on the > >> device and what local resources it can access. > Well, most application are either: (1) supplied by a developer and > self signed; or (2) supplied by a vendor with signatureOrSystem. For > examples of (1), Google Play is full of them. For an example of (2), > look at the manifest of the bloatware packaged with phones by carriers > and handset manufacturers. > > The four platform keys essentially establish four CA's, but there's > something that's lost in the translation. At best, I think its a > private PKI. Its not a traditional, public PKI like PKIX with hundreds > of trusted CAs and subordinate CAs. See, for example, > http://www.kandroid.org/online-pdk/guide/release_keys.html. > > > while quouting Elenko's article: > > > >> Android solves this problem quite simply: it doesn't care about the > actual > >> signing certificate. Thus you do not need to have it issued by a CA > >> (although you could, and most will happily take your money), and > virtually > >> all code signing certificates used in Android are self-signed. > I think Nikolay pretty much nailed it for the common case. > > With that said, you could go to Verisign and get your end entity > certificate signed. But it does not really provide any benefits. Your > app's trust zone or security boundary is still created based on your > end entity cert. It does not matter that Verisign endorsed or > certified your public key. > > The Android OS does not have a built-in trusted store, so public CAs > like Verisign mean nothing for the platform's private PKI. Your signed > app *cannot* get 'system' in signatureOrSystem via an endorsement from > Verisign. That's what the platform keys are for. > > > That means if and only if someone uses a certificate issued by a CA, > this > > app is vulnerable to this type of attack? That means if there is a > > certificate that looks like it was signed from a CA > I don't believe so. It does not pivot on a public CA. Android does not > include a built-in trust store. Android utilizes a private PKI and > uses the platform signing keys for that. >
Are system apps signed with a different key that is signed by the platform key? When i take a look into the /data/system/packages.xml i see 3 keys there, installed by default. All of these keys are self-signed. > > What's not clear to me (but I don't believe it matters): does a > platform key sign (or countersign) the adobe component? Or is the > adobe component trusted via "hard coding" the trust into the source > code. > I do not found the specific Adobe app he is talking about but i checked other Adobe apps from the market and they are signed by Verisign. So this Adobe webview plugin comes preinstalled with certain devices? I do not see the need to sign the key of adobe's app with the platform key, but maybe there is a reason. > > The implicit trust in the adobe component *coupled* with the incorrect > verification is the crux of the problem. If you find another > implicitly trusted component that includes an Issuer, then you have > probably found another hole. But again, it does not need to be signed > by a public CA. It just needs an issuer whose name you can fake. > > > this would make sense to me. > Yes, you're close. But its not centered on public CAs. Its focused on > the trust of a component, and exploitable because of a gap in the > verification routines. Namely, the string comparison of the > distinguished names (versus the verification of a signature). > > i understand, thanks a lot! > Jeff > > > Am Mittwoch, 30. Juli 2014 14:03:28 UTC+2 schrieb Jeffrey Walton: > >> > >> On Wed, Jul 30, 2014 at 4:58 AM, reox <[email protected]> wrote: > >> > ... > >> > > >> > I do not understand what is the problem here? Does anyone have more > >> > information? > >> Taking from the 4th paragraph under "How It Works": > >> > >> <quote> > >> The Android package installer makes no attempt to verify the > >> authenticity of a certificate chain; in other words, an identity can > >> claim to be issued by another identity, and the Android cryptographic > >> code will not verify the claim > >> </quote> > >> > >> *If* I am reading the 4th paragraph correctly, it appears (and using > >> Adobe as an example): > >> > >> The app is using a certificate that is *not* self-signed. The app's > >> certificate has an Issuer Distinguished Name of Adobe. However, the > >> system does not verify Adobe actually issued the app's certificate The > >> verification system is just performing a string comparison of the > >> distinguished names. > >> > >> Actually, that is the case. From the 6th paragraph: > >> > >> <quote> > >> ... instead defaulting to simple subjectDN to issuerDN string matching > >> </quote> > >> > >> To summarize, signature verification on the chain is not being > >> performed. Rather, a simpler [insecure] algorithm is used that > >> consists of Distinguished Name matching. > >> > >> I attached an image that shows the relationship between Issuers and > >> Subjects. It was ripped from Peter Gutmann's Engineering Security book > >> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). It should help > >> you visualize what's going on. > >> > >> That's another good find by Forristal. > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
