danielku15 / signingserver Goto Github PK

Description

• pack and publish a container image (ghcr should be OK, no docker hub)
• Enable environment variable configuration
• Ensure we ship an empty runnable config in the image which can be extended from outside.

Would be nice to replace the old-school WCF with ASP.net core and HTTP based communication.
For keeping the TCP overhead small we would need to use Keep Alive connections within one request.

Performance and parallelization might get a bit a boost due to it.

But it would be a breaking change to migrate the protocol again.

There are some breaking changes in the new bouncycastle we have to investigate and fix before upgrading.

Signing Failed with error 'Failed to determine APK's minimum supported Android platform version' when trying to sign an AAB (APK signs normally)

AAB build info:

• targetSdkVersion="33"
• minSdkVersion="29"
• Android SDK Buld tools v 32 used

Some people had similar issues and they just used the hack (not really a solution) :
C:\Android\build-tools\30.0.3\apksigner.bat sign --ks my-release-key.jks --out signed.aab --min-sdk-version 14 TestAligned.aab
(I had to add the "--min-sdk-version 14" to fix the error: "Failed to determine APK's minimum supported platform version.")"

Description

Currently we perform a separate signing operation for each file to validate that the certificate is operational (as workaround for faulty certificate objects).

It would be better to attempt the real signing operation and only perform this recovery operation if things fail during signing.

https://android.googlesource.com/platform/tools/apksig/+/5be82c38d60ef3c1d9fc42bdbca8495434c88f0d

Use Case: Use Certificates from an Azure Key Vault instead of local CertStore

Description

The parallelism option should be available per-certificate instead only on global level. Software level certificates are only limited by the CPU resources while for HSM we might want to limit the parallelization to not overload the device.

Potentially we also need a global parallelization limit as we know that some HSMs have poor handling of concurrency on their own and even requests from multiple clients need to be synchronized.

As a counterpart of #21 where signatures can be generated, also the certificate (public key) is needed to have a fully automated workflow where signing and verification can be integrated well.

Description

Instead using a username-password based auth, there should also be the option for an OIDC based auth which validates JWT bearer tokens.

In alignment with #47 there needs then to be a different way of controlling the access to certificates for users.

Some ideas:

• Check if user has a specific claim value set.
• Manual configuration
• For Azure KeyVault / Hashicorp vault certificates: Pass-through authentication token and certificate selection details to the key-vault let the certificate management decide.

Use Case: Sign APKs and AABs with V1-V4 Signature Schemes.

I tried out the Dev branch and noticed that the client will report that the sign request succeeded, even if it didn't, e.g. due to an auth failure.

Server & Client logs (from the same sign request):

Server.txt
Client.txt

Server & Client config (wrong password in client config is intentional to demonstrate the issue):

config.json.txt
appsettings.json.txt

Best regards

In some scenarios it is not preferrable to have the token pins encrypted with the local system data protection as they are system dependent. When supplying configs

• for testing purposes
• from an external configuration source (env vars, azure keyvault config,..)

A plain text configuration is preferrable.

Usecase: Host this Signing Server in an Azure environment.

To be checked:

• What communication protocol to use? (HTTP with CoreWCF instead of NetTcp, new ASP.net core communication channel)
• Hosting mechanism? (Docker Container vs Azure App Service).
• Ensure high level of security on access to service. (Add support for Azure AD Access Tokens for first level authorization, transport security).

The SigningServer has currently a limitation of a 1:1 between input and output. But with APK v4 signing the output is the APK and an idsig file. With #8 we must consider in the API that there might be a 1:n on input:output. Adding this support in the WCF version Would be likely tricky due to the streaming limitations in WCF.

Description

Idea:

• Use Hashicorp Vault for signing operations (authenticating against Vault then do signing with a cert)
• Develop a Hashicorp Vault extension/module/plugin that can offer code signing as an API integrated into the Vault.

Description

Currently there is a basic user authentication with username/password and each user has a single certificate.

This should be changed that we have N certificates (with given names) and for each user a list of certificates he can use (first one default).

Then the client can list out all certificates and opt-in for a differnet one during signing.

The PortableExecutableSigningTool could also be ported to .net using PInvoke calls, this would eliminate the need of C++ compilation.

An aab can be signed by renaming it to *.jar, but it will only be signed with SHA1 even though the configuration file contains "HashAlgorithm": "SHA256".

This can be verified by using
jarsigner -verify some.jar -verbose

output:

Digest algorithm: SHA1 (disabled)
Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01, include jdk.disabled.namedCurves

https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools