According to the Telegram docs, to subscribe to web push notifications, you need to pass the following:
A JSON-encoded object with the following keys:
endpoint: Absolute URL exposed by the push service where the application server can send push messages
keys: P-256 elliptic curve Diffie-Hellman parameters in the following object
p256dh: Base64url-encoded P-256 elliptic curve Diffie-Hellman public key
auth: Base64url-encoded authentication secret
What is the last key, auth is referring to?
This question is related but doesn't really answer my question.
EDIT: Here is some sample code to generate the keys per Wizou's solution.
As mentioned in the doc, payloads can also be encrypted using P-256 Elliptic Curve Diffie-Hellman when using web push.
As per the linked RFC, this encryption requires a public key, and an authentication secret.
In Section 3.2, the RFC specifies that you should generate this secret by providing a hard-to-guess sequence of 16 octets that is used for authentication of push messages. This SHOULD be generated by a cryptographically strong random number generator [RFC4086].
Related
I am trying to implement an authentication/authorization system using firebase and I am struggling with the last part of the authorization flow, which is, enabling my server to verify the validity of a token.
There are two ways to perform this:
Validate the token using the Admin SDK of firebase, where essentially a server communicates with Firebase and validates a token (safe option)
Validate the token using a third-party JWT library.
My question has to do with option (2), which according to documentation is perfectly feasible. The question is, how is this safe? Everything included in the token-validation process is public according to this:
Finally, ensure that the ID token was signed by the private key corresponding to the token's kid claim. Grab the public key from https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com and use a JWT library to verify the signature. Use
If the token is public, and the key for validating it is public, who guarantees that the token is genuine?
Probably there is something related to JWTs that I am missing?
PS. I have already implemented option (1) with remote validation, but this will significantly affect the application performance.
You can verify validity of a token with the public key, but you can only create tokens with the private key.
As their names imply:
Your private key should only be used in trusted environments, such as your development machine, a server you control, or Cloud Functions. So those are the only places where you can generate auth tokens.
The public key however can be shared with others, which means that they can use it to ensure that the token is valid.
I am using a local URL scheme to submit a payload to the client when a user clicks a link and have to make sure that this is only used in my specific web application.
So I am using a key pair, encrypting the payload on the server using the private key, generating a link that the protocol handler on the client can decrypt using the public key, verifying that the payload should be processed.
So is it less secure to send a private-key-encrypted payload instead of a cleartext payload plus signature (and if yes, why)?
Found out that there are other Stack Exchange sites that answer this question very well:
https://crypto.stackexchange.com/questions/2123/rsa-encryption-with-private-key-and-decryption-with-a-public-key
https://security.stackexchange.com/questions/11879/is-encrypting-data-with-a-private-key-dangerous
I should have searched a little bit longer before asking.
What you are doing is signing!
Encrypting is when a payload is being concealed with one’s public key and later decrypted with a private key. When I want to send you a secret message, I will take your public key (because I know it) and encrypt my message. This will make sure that only you can decrypt it with your private key.
Signing works vice versa. If during encryption I want to make sure that only you can decrypt me message, with signing I want to make sure that all recipients of the message can be sure in its authenticity. If you encrypt something with your private (signing), anyone with your public key can decrypt it and verify its sender.
In your case, if you just want to prove your identity (like certificates, jwt tokens, etc.), you would need to use signing methods. If you want to transfer payload securely, use encryption.
Hope this helps!
I develop phoenix app that uses Firebase as an external authentication service. I use Joken library. It requires me to use function with_signer that needs a cryptographic key. I suppose this is the key that JWT was signed with by Firebase. The question is - am I right in my assumptions? And more importantly - where do I find this key?
Firebase should publish a public key at a well known address that you can use to validate the JWTs.
The docs suggest:
Finally, ensure that the ID token was signed by the private key
corresponding to the token's kid claim. Grab the public key from
https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com
and use a JWT library to verify the signature. Use the value of
max-age in the Cache-Control header of the response from that endpoint
to know when to refresh the public keys.
Lately I have been reading some about JWT/JWS and JWE.. however.. one part I still dont get is that Im quite sure that I somewhere have read that they all should be "stateless", is this true?
My take on this would be that JWS and JWE would require a shared secret between the "acquirer" and the "issuer" to be able to decrypt the payload (and CEK and what not depending on JWS or JWE).
So my question is.. is JWS and JWE truly stateless? And if thats the case, then how come we dont need to store a secret between the "acquirer" and the "issuer"? Or is the kid used for fetching our secret from for instance a database to decrypt the payload and/or CEK?
To clarify,
Is there a shared secret between the issuer and the acquirer when using JWS and/or JWE to decrypt and encrypt the token? Is this secret stored in a database on the issuer to be able to decrypt the payload and/or the CEK or is the secret/key used to decrypt and encrypt shared some other way?
This question is based on the following article regarding JWT,JWS and JWE:
https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
You are right: Depending on your application, it may be stateful.
From my point of view, you could ditinguish two cases:
Your application issues JWE or receives JWS
Your application issues JWS or receives JWE
With the first use case, the JWS signature can be checked using the issuer public keys. These keys are (broadly speaking) shared with the parties by the issuer (this what Google and other authorities do). Same goes when you want to encrypt a token (JWE) to that recipient: you will use its public key.
With the other use case, your application will need to have access on a key set with private keys. Those keys are necessarily stored somewhere (a DB, an environment variable...).
When shared keys are used (rarely used with 3rd parties), you may be in the use case #2 as both the issuer and the recipient have to manage the shared key.
I'm creating an app (C#) that is going to send some messages around the network. Outgoing messages will be signed by a private key, incoming messages decrypted with a private key.
In case someone steals the private key, I want to be able to revoke it (send a revocation message to all other clients). Since I'm the owner of the stolen private key, only I must be able to revoke it.
My question: Is it possible to create a public/private key pair, depended on a so-called "Master public/private key pair" I have created before, to use in my app and if the private key in the app got stolen, I can revoke it, because with the master key I can proof that I'm the owner?
Hope someone understand what I mean ;-)
Mike
Update 1:
I'm developing a peer-to-peer app, so there will be no central server / CA
I'm generating the public/private keys by using the RSACryptoServiceProvider class in C#
Basically you'll design a system where each client can receive messages signed from two private keys: if they receive a message from the second private key, it will discard anything received signed with the first key.
Seems to be simple...
So, I think that you meant that you want to "revoke" the first public/private key in a way that your system will consider this pair invalid independent of same processing, I mean, even if someone hack the client, it won't be able to accept the first compromised key pair, because somehow they're revoked by the second key pair.
Is that it?
If so... no, without some kind of server, I don't think you can "revoke" a key pair. Revoking implies in having a central server telling which keys are valid, or your application doing this check internally (for ex., receiving a message from the second key pair and processing it)
You want to wrap you keys in a X.509 Certificate. The certificates should have a revocation Authority that supports OCSP (Online Certificate Status Protocol). see http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
You don't need a second key (and if you did - what if an attacker stole that?) Simply define a 'revocation' message type which indicates the key that signed it is revoked (irrevocably, as it were). If your key gets stolen, you simply have to send out the revocation message using the stolen key, and the key becomes useless to the attacker.
How to distribute the revocation message depends on the system you're using, of course, but I'm assuming here that you have some way to distribute keys already, and therefore revocations can take the same route.