This is very similar to the AuthCredential used by the group server,
but using CallLinkParams to encrypt the user ID rather than
GroupParams (and using GenericServerParams to issue the credential
rather than the group server's ServerParams).
This will allow a user to request to create a call link from the chat
server without revealing anything about the room, and then later
actually create it by giving the room ID to the calling server without
identifying themself.
This involves a new, stripped-down GenericServer{Secret,Public}Params,
which currently only contains a generic "zkcredential" key. Apart from
the calling server not needing to handle all the credentials that the
group storage server supports, the structure of zkcredential means it
is safe to use the same key for multiple kinds of credentials.
Similarly, CallLink{Secret,Public}Params plays the same role as
Group{Secret,Public}Params for encrypting user IDs when talking to the
calling server.
Following from that, the APIs for CreateCallLinkCredentials are
located on the individual types (RequestContext, Request, Response,
Credential, Presentation) rather than all being on the Server*Params
types; adding a new credential type won't change the API of the
Server*Params types at all.
The main Server*Params may make use of zkcredential in the future as
well, but for now it's only for new Signal servers that want to use
zero-knowledge credentials.
- We weren't loading the native library as "signal_jni.dll"
- The Gradle build commands, though still requiring a shell environment,
shouldn't rely on Unix-style #! lines to execute shell scripts
These are intertwined: older versions of Rust don't support the newer
NDK, but the newer Rust can't successfully compile BoringSSL against
the older NDK.
This requires a boring-sys update to find the Android NDK sysroot in
the right place.
Currently the only user of this method is the ProtcolException constructor,
when a UnidentifiedSenderMessageContent is present.
All other instances of ProtocolException use the sender's UUID as sender.
So it would be good to have this consistent.
Also brings this in line with similar methods, like `getSourceIdentifier` on
SignalServiceEnvelope.
Removes AuthCredentialPresentationV1 and PniCredentialPresentationV1
entirely. For ProfileKeyCredentialPresentationV1, there are still
situations where we want to extract the UUID and profile key, so we
continue to support parsing only.
-i (interactive) and -t (allocate a tty) allow the shell running
inside Docker to handle Ctrl-C (^C) and other shell commands, so you
can stop a command in the interactive process you ran it. However,
they only work if the containing shell (the one where you ran `docker
run`) is also interactive with a tty hooked up, so we test for that
first in both scripts that invoke `docker run`, using `test -t`.
--init passes signals from *outside* Docker down to its subprocesses,
so that cancellation from *another* context works for our Docker
images. This includes the Cancel button in GitHub Actions.
This was previously in the Java layer because it only really affects
the server, but it's more consistent to have all verification in the
Rust layer. We do lose the separate exception type for it, though.
Adds a java method for libsignal-server that enables extracting
attestation metrics from serialized evidence and endorsements.
Certificate and endorsement validity periods are exposed, so servers
can track if any attestation material is overly stale.
- Use the headless variant of the JDK.
- Put most apt-get requirements at the end of the file, so that
tweaking them can make use of Docker's per-RUN line caching.
- Added 'clang' as a build dependency for BoringSSL.
- Drop unnecessary packages:
- apt-transport-https - we're using plain http sources at this time
- build-essential - overkill, we just need 'make'
- gcc-multilib - was used to build OpenSSL for testing,
no longer necessary with the switch to BoringSSL
- openssh-client - was used to clone from GitHub, now unused because
all dependencies are public
And note that the "slow tests" should also be passing before a
release.
Implements (a subset of) Intel's DCAP attestation,
making heavy use of 'boring' for X509 and ECDSA.
Cds2Client is now ready for use!
Co-authored-by: Jordan Rose <jrose@signal.org>
Co-authored-by: Ravi Khadiwala <ravi@signal.org>
This is a variant of AuthCredential that carries two UUIDs, intended
to be a user's ACI and PNI. Why? Because when you've been invited to a
group, you may have been invited by your ACI or by your PNI, or by
both, and it's easier for clients to treat all those states the same
by having a credential that covers both identities. The downside is
that it's larger (both the data, obviously, but also the zkgroup proof
of validity, unsurprisingly).
AnyAuthCredentialPresentation gains a 'get_pni_ciphertext' method,
which will return `None` for the existing presentations and
`Some(encrypted_pni)` for the new credential. Having a separate
credential type but a common presentation type makes it easier for the
server to handle all possible credentials uniformly.
This term is unnecessary after all (the value of 'z' is already fixed
by the equation "Z = I^z"). We can't remove it from earlier proofs
because that would change the format, but going forward we don't need
it.
Like ProfileKeyCredential, but with an expiration timestamp embedded
in it. This has its own credential type and response type, but uses
the same request type as a "classic" ProfileKeyCredential, and
generates presentations usable with AnyProfileKeyCredential-
Presentation, so that existing server code accepting presentations
will automatically do the right thing.
Adoption for servers:
- Update secret params
- When presentations are saved in group state, use
ProfileKeyCredentialPresentation.getStructurallyValidV1PresentationBytes()
to maintain backwards compatibility with existing clients.
- Add an endpoint to issue ExpiringProfileKeyCredentials
- (future) Remove the endpoint that issues regular ProfileKeyCredentials
Adoption for clients, after the server has updated:
- Update public params
- Start fetching and using ExpiringProfileKeyCredentials instead of
regular ProfileKeyCredentials (the old endpoint will eventually
go away)
- Node: To bring types into harmony, a receipt's expiration time has
been changed to a `number` instead of a `bigint`
This trades speed for size around certain elliptic curve operations in
BoringSSL. We're using boring mostly for verifying certificates, not
the many many curve operations we do on a per-message basis, so for
now the code size is more important.
Upcoming work in `attest` requires additional X509 support, and swapping these libraries
is a negligible impact on binary size. This uses a fork of `cloudflare/boring`, as
we have some additions that haven’t yet been contributed upstream.
