| 67096e08a72beea85979a3aa9fc5b376b2c2b5ad |
28-Dec-2017 |
Daniel Cashman <dcashman@google.com> |
Add APK Signature Scheme v3.
Add ApkSignatureSchemeV3Verifier to enable APKs to be signed with
the new signature scheme. Update the ApkSignatureVerifier to process
the results, but only pass on what's needed for the existing interface.
In the process, move the ApkSignatureSchemeV2 code into a common
area for use by any scheme that makes use of the APK Signature Block.
The primary purpose of APK Signature Scheme v3 is to enable applications
to rotate their signing key. This is accomplished by augmenting APK
Signature Scheme v2 to also include a new Proof-of-rotation struct, which
is fundamentally a singly linked list where each of the APK's signing
certificates is included in order, along with a signature over the next
certificate. Thus, each certificate contains proof that the private key
corresponding to the previous one blessed it. This provides evidence to
the platform that the new signing certificate should be as trusted as
the previously trusted one. This structure also includes some flags for
each certificate to indicate to the platform how the APK itself would
like to interract/trust the old certificates.
Bug: 64686581
Test: Builds, boots, passes
android.appsecurity.cts.PkgInstallSignatureVerificationTest
Change-Id: I0f98ff13950af78f5d9b269f80d13af8891f7a2d
trictJarVerifier.java
|
| b061fc2bb5b6e8397c7f3a40be521badad91e9af |
06-Dec-2016 |
Tomasz Mikolajewski <mtomasz@google.com> |
Fix crashing StrictJarFile due to doubled closing.
If the constuctor throws, then the handles would be closed without
setting "closed" to true. As a result, the finalizer would close
the handles again, which would cause a crash on the native side.
Test: Unit tests are no longer flaky.
Bug: 33301253
Change-Id: I527ba38d5d65ce844258d894441d4fe16bac6e23
trictJarFile.java
|
| 9f00d71787774bf79d4b398c28630f670765b791 |
02-Dec-2016 |
Tobias Thierer <tobiast@google.com> |
Migrate StrictJarVerifier and ShortcutPackageInfo to java.util.Base64
Previously, they weres using libcore.io.Base64, which is @deprecated.
The two implementations' encoders produce the exact same result.
The two implementations' decoders' behavior differs for malformed
input:
- In case of error, libcore.io.Base64.decode() returns null while
java.util.Base64.getDecoder().decode() throws.
- java.util.Base64 tends to be stricter about rejecting malformed
input; specifically, it allows neither whitespace nor unexpected
'=' characters (should only occur in the padding) whereas
libcore.io.Base64.decode() leniently allows them throughout the
input.
- if the input terminates prematurely, libcore.io.Base64 tends to
return fewer bytes (stops at a four byte boundary).
The behavior differences for malformed Base64 encoded data should
not affect ShortcutPackageInfo because it should only need to deal
with XML attribute values written by itself, which are well-formed.
Note that this CL does not lead to any known changes of the encoding
step, so values written by earlier versions should not cause problems
when read by later versions of ShortcutPackageInfo.
StrictJarVerifier may now reject or behave differently for .jar /
.zip files with malformed attribute values but this seems okay since,
per its name, it is meant to be strict. For example, after this CL,
StrictJarVerifier will no longer accept algorithm + "-Digest"
attribute values with extra whitespace or padding characters as valid.
Test: Confirmed that the two implementations' encoders produce the
same result by running the following code just before this CL:
assertEquals(
libcore.io.Base64.encode(allBytes()),
Base64.getEncoder().encodeToString(allBytes()));
where allBytes() returns a byte[] with values (byte) 0 .. (byte) 255
Test: Test that phone still boots after flashing code that includes
this CL.
Test: CtsLibcoreTestCases
Bug: 31292683
Change-Id: I775d32f329f693514a8f14d87e1ef0d7a757e6c3
trictJarVerifier.java
|
| 6c3df1543cb85d5ff7ebb2b026d7a34184465c7b |
20-Oct-2016 |
Tomasz Mikolajewski <mtomasz@google.com> |
Add support for opening JAR/ZIP files via FD.
Test: Upcoming change in DocumentsUI uses this feature.
Bug: 31783726
Change-Id: Ia74e9bdb66722dfb2855380375a99cc94d288b2e
(cherry picked from commit 5a5c44a2e30a55843802b472f2f8be81496bbd25)
trictJarFile.java
|
| 2ffb7ebae275d6a66cae2d0806fb094717acc5d1 |
09-Aug-2016 |
Neil Fuller <nfuller@google.com> |
Merge "Add a finalize() method to StrictJarFile"
am: d0c0c8dcab
Change-Id: Iccab49c98b105aff6105e21274fbc099d10ecb55
|
| b69f61472a25cff07cb9cc139e26e50c5af20394 |
03-Dec-2015 |
Neil Fuller <nfuller@google.com> |
Add a finalize() method to StrictJarFile
Bug: 25896372
Test: Booted device, installed CTS apps
Test: run cts --class android.util.cts.StrictJarFileTest
Change-Id: I35e238dadd48d2c4ca53ac37a4c5aacdd471a93a
trictJarFile.java
|
| 29045203f3f694cddea7b3f115ea82f648ba0cba |
01-Jun-2016 |
Alex Klyubin <klyubin@google.com> |
Use correct cert chain from PKCS#7 SignedData block.
This fixes a bug where APK JAR signature verifier returned the wrong
certificate chain. Rather than returning the cert chain of the
verified SignerInfo, it was returning the bag of certs of the PKCS#7
SignedData block.
This issue was introduced in Android N and thus does not affect
earlier Android platform versions.
Bug: 29055836
Change-Id: I684c0f8e9ff47b922030645e07b6a114c0eb0963
trictJarVerifier.java
|
| 9b59bc459b4cb5415909641bd1e981100bfafb2b |
24-Mar-2016 |
Alex Klyubin <klyubin@google.com> |
Ignore signature stripping protection for preinstalled APKs.
The current build process may currently strip APK Signature Scheme v2
signatures from prebuilt APKs to be installed on the system or vendor
partitions. However, it leaves intact the signature scheme rollback
protections introduced by APK Signature Scheme v2. Due to a bug, when
the system extracts signer certificates from preinstalled APKs, it
encounters the rollback protection and aborts the extraction process.
This manifests itself as some preinstalled packages not appearing as
installed.
This change makes the system ignore signature scheme rollback
protections when extracting certificates from preinstalled APKs. This
is fine because the process of extracting certificates from
preinstalled APKs does not care about validity/integrity of signatures
and the APKs. It only cares about extracting signer certificates.
Bug: 27829513
Change-Id: I3bed463e776b057e93a0fce915db4014946be1f9
trictJarFile.java
trictJarVerifier.java
|
| e415718502897a4e5385af47d3bbe8c8257c2e5d |
05-Jan-2016 |
Alex Klyubin <klyubin@google.com> |
Verify APKs using APK Signature Scheme v2.
This makes Package Manager check whether an APK is signed using APK
Signature Scheme v2 and, if it is, verify the APK's signatures using
that scheme rather than the usual JAR signature scheme.
APK Signature Scheme v2 is a whole-file signature scheme which aims
to protect every single bit of the APK as opposed to the JAR signature
scheme which protects only the names and uncompressed contents of ZIP
entries.
The two main goals of APK Signature Scheme v2 are:
1. Detect any unauthorized modifications to the APK. This is achieved
by making the signature cover every byte of the APK being signed.
2. Enable much faster signature and integrity verification. This is
achieved by requiring only a minimal amount of APK parsing before
the signature is verified, thus completely bypassing ZIP entry
decompression and by making integrity verification parallelizable
by employing a hash tree.
Bug: 25794543
Change-Id: If59fe013f2e62bac7677bb20e65f6061b91eec2e
trictJarFile.java
trictJarVerifier.java
|
| 6a8ad6d161d6846311267f5e4aa933b8490bc821 |
03-Nov-2015 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
Move StrictJarFile from libcore to framework
Bug: 25337946
(cherry picked from commit 8a7c1606d88873c5a1b5764c16cb046b6f2275b2)
Change-Id: I1bfce4129887d7cbfc02d92641b44920d7cdbbee
trictJarFile.java
trictJarManifest.java
trictJarManifestReader.java
trictJarVerifier.java
|
| 8a7c1606d88873c5a1b5764c16cb046b6f2275b2 |
03-Nov-2015 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
Move StrictJarFile from libcore to framework
Bug: 25337946
Change-Id: Ib4fac6fa9f534b8654e5ca158bbaedb2393772ba
(cherrypicked from 43ea2cc2a81926a6b2ca13d41f4eab089640129e)
trictJarFile.java
trictJarManifest.java
trictJarManifestReader.java
trictJarVerifier.java
|