I'm building an app that I want to have E2EE. My struggle is with the private keys. Most of what I read they say you don't store it in AWS servers because it will not be an E2EE anymore and it's a backdoor. I don't want to create a backdoor, I want the user ONLY to hold the key. However, at the same time if the user logged in from another device, they cannot retrieve their data coz the private key on the original device.
So what are some ways to let the user be able to login from another device without having a trouble retrieving the data and not putting their private key on risk!
Please consider that I'm new to this subject and I'm using cryptoKit from Apple :)
Thanks!
You can use the user’s id and password hash (for example) to encrypt the private key and store the encrypted version of it on the server.
Encrypt the private key locally using the user's id and password (or a hash of it)
Send this encrypted key to the server to store it there
Now when the user logs in from another device, the encrypted key can be retrieved and decrypted locally using the user's id and password.
Thus, it won’t be possible to decrypt and use the encrypted key without the user’s credentials. However, this also means that if the user changes their password, the encrypted key also needs to be decrypted with the old and re-encrypted with the new password.
That’s the usual approach for your requirement.
So, i am making a flutter app for my client. For uploading the app on playstore am generating the
upload key(.jks).I want to know whether on generating the key for the playstore can anyone take any important content from that key. Like can someone use that key to get data from my laptop or misuse it in any form. Is it safe to generate the key then upload app on playstore from your laptop and then give key to the client?
The JKS file will contain the key and a certificate associated with the key:
The key is only two or three very long numbers.
The certificate associated with the key contains information such as Name, Company, Country, etc. (which you should have been prompted for when you created the certificate).
The key and certificate will only allow the client to sign future APKs/Bundles to upload to the Play Console, that's all. So yes, it's safe to give the JKS file to the client (assuming it was created just for that app).
how do I create a Key-pair in the Secure Enclave, which I can access from the System Keychain?
For a internal project, I need a AD Certificate, where the private key should be stored in the SE. For this I write a Swift Application which generates a key pair in the SE and build a CSR from this.
Now I have created a AD Certificate out of the CSR. Because of the Keychain access groups I can't access private key.
Is there another way to create a key pair in the secure enclave where I can access the private key from the keychain? Or does anyone know how to connect with the Certificate to a company Wi-Fi / VPN?
I'm implementing a sign in system with the help of the JWT (JSON Web Token) scheme. Basically, after a user sign in / login, the server signs a JWT and passes it to the client.
The client then returns the token with each request and the server verifies the token before sending back a response.
This is pretty much how you would expect it, but I'm having some problems with the logic of the process. From all the mathematical articles I've read, it seems that RSA signing uses asymmetric keys for signing. As the public key, as its name suggests, is exposed to the client and the private key is kept on the server, it makes sense to sign the JWT with the public key which is sent to the client and verify it on the server side using the private key.
However, on every example and library I see it seems to be the other way around. Any idea as to why it is so? If a JWT is signed with the private key and verified with the public one than whats the point?
First off, apologies, this answer got rather long.
If you use RSA to sign your tokens, and a connecting client is a web browser, the client will never see the RSA keys (public or private). This is because the client presumably doesn't need to verify that the JWT is valid, only the server needs to do that. The client just holds onto the JWT and shows it to the server when asked. Then the server checks to make sure its valid when it see's the token.
So why might you need a public / private key combo for JWT's? Well first off, you don't need to use a public / private key algorithm.
You can sign JWT's with a number of different algorithms, RSA being one of them. Other popular choices for signing your JWT's are ECDSA or HMAC algorithms (the JWT standard supports others as well). HMAC, specifically, is not a public / private key scheme. There's just one key, the key, which is used to both sign and validate the tokens. You can think of this as using the private key for both signing and validating the JWT's. I'm not an expert on this by any means, but here's the conclusions I came to from doing my own research recently:
Using HMAC is nice because it's the fastest option. However, in order to validate the JWT's, you need to give someone the one key that does everything, Sharing this key with someone else means that that person could now also sign tokens and pretend like they're you. If you're building multiple server applications that all need to be able to validate your JWT's, you might not want every application to have the ability to sign tokens as well (different programmers might be maintaining the different applications, sharing the signing ability with more people is a security risk, etc). In this case, it's better to have one, tightly controlled private key (and one app that does the signing) and then share the public key around with other people to give them the ability to validate the tokens. Here, the private key is used for signing the tokens, and the public key is used for validating them. In this case you'd want to choose RSA or ECDSA.
As an example, you might have an ecosystem of apps that all connect to
the same database. To log users in, each app sends folks to one,
dedicated, 'logging in' app. This app has the private key. The other
apps can verify that the person is logged in using the public key (but
they can't log people in).
The research I've done points to RSA being the better option for most JWT apps in this scenario. This is because your app will be, theoretically, validating tokens frequently. RSA is much faster then ECDSA at verification. ECDSA is primarily nice because the keys are smaller in size. This makes it better for HTTPS certificates because you need to send the public key to the client's browser. In the JWT scenario though, the keys are staying on a server so the storage size is n/a and the verification speed is more important.
Conclusion: if you're building a small app without multiple smaller 'micro-service apps' / you're the only developer, probably choose HMAC to encrypt your keys. Otherwise, probably choose RSA. Again though, I'm not an expert, just someone who recently googled this topic, so take this with a grain of salt.
There is a difference between signing/verifying and encrypting/decrypting data but the semantics can be similar.
You sign data with a private key that only controlled sources have so anyone who receives the information can use your public key to validate this information was indeed sent by you and is the same information you intended to send out.
You encrypt data with a public key and decrypt with a private key. This sounds opposite but really follows the same logical concept as signing. If you want to send data between person A and person B, both people have a public/private key pair and they share their public keys with each other when they meet (handshake). A constructs a message for B and encrypts it using B's public key and sends it to B. Now, no one without B's private key can decrypt that message including A - even though they originally sent it.
In terms of JWT, a JWT payload by itself is just Base64 encoded JSON with some standardized fields. The signature allows someone with the public key to validate the information hasn't been altered by someone in the middle. Similar to a checksum but with some extra security based warm fuzzy feelings. The contents of the signed JWT are easily visible (base64 is encoding like unicode or utf-8, not encryption) to the end user and anyone in the middle which is why it is generally frowned upon to send sensitive data in a JWT like passwords or PII.
As others have mentioned, most JWTs contain information not intended for clients but to help facilitate the stateless part of RESTful services. Commonly, a JWT will contain an accountid, userid and often permissions as "claims". An API endpoint can verify the signature and reasonably trust the claims to not be altered by the client. Having the client send the JWT for each request saves the endpoint having to do a lot of database back and forth just to get where they are by simply verifying a signature with a public key.
Additionally, signed JWTs can be encrypted. According to the JWE spec, the payload is encrypted after signing and then decrypted before verifying. The trade off here is that all endpoints must also have the private key to decrypt the JWT but end users won't be able to see the contents of the JWT. I say trade off because in general private keys are meant to be kept secure and a widely distributed private key is just less secure. Security, risk assessment and cost/benefit of encryption is a whole other beast :)
Your suggestion:
it make sense to sign the JWT with the public key which is sent to the
client and verify it on the server side using the private key.
is not correct. Signing is done with the private key of the sender, encryption is done with the public key of the receiver. That is how PKI works in general.
For iphone push notifications SSL certificates, you need to provide them with CSR files...
I have saved a CSR file since some time now, and i always give upload the same CSR file, whenever i want to generate the SSL certificates...
Now i've been thinking, since when generating CSR files, i'm actually generating the private key, and probably the public key too...
So i'm wondering what disadvantages i'm facing when i'm using the same CSR file.. though when i download the SSL Certificates, they appear in the keychain as if there's multiple private keys (though they have the same name) and each is attached to a different SSL Certificate.
Is it recommended to generate a new CSR file everytime? and why? and if it's not necessary, then how?
thank you
Certificate Request contains the public key and you have an associated private key. So by re-using it you basically get the same key pair signed again and again.
The disadvantage is obvious - if one key gets leaked, you get all certificates compromised. This is why re-generation of key pairs each time is necessary.