Alice wants to know from Bob the location of a sensitive resource. Bob Kindly tells Alice the location, but how can Alice be sure of the identity of Bob?
Bob is a OpenBSD server, and the source of data is a Python/C++ App.
My Idea was:
Alice Knows Bob's public Key.
Alice encrypt a random string with Bob's Public Key, and send it to Bob.
Bob recover the random string, and hash it. Bob send back the sensitive resource, along with the hash.
The problem of this method is: Can I safely store a private key on Bob (the server)? How? Is there a better solution?
If Bob doesn't have a private key, then what else does Bob uniquely know that it can use to identify itself? And if you can't trust Bob to keep its private key safe, you're sunk no matter what you do.
If it's worthwhile spending the extra money, one thing you could do is have another machine (call it Cipherclerk) that is not online, can communicate only with Bob, and will only make certain kinds of communications. Cipherclerk holds the private key, and uses it to decrypt things for Bob. Then, even if Bob is compromised remotely, at least the private key isn't compromised with it.
An enhancement to your idea would be to have Bob use Alice's random string as a symmetric key to encrypt the resource.
This method is completely insecure if someone can mount a man in the middle attack. Mallory, the attack, can simply strip the the sensitive information out, substitute it with hers, and forward it on to Alice.
The solution is to use TLS or SSH. In either case, make sure Alice has bob's public key or key fingerprint. This is a widely used solution and is secure assuming no one can change the data Alice stores or read the data bob stores.
Related
So I have a document shared between two or more users. Call them Alice and Bob.
When editing this document, Alice is signed in using OAuth with office 365 or google gsuite; I'll call that an identity provider.
When I pass this document to Bob, I want to be able for Bob to have confidence that the content written by Alice was indeed written by someone with the ability to sign in the identity provider as Alice.
The obvious way to do this is for Alice to digitally sign the changes in the document with a public/private key pair, and then connect the public key to her own identity.
This will require that Bob can get at that public part of the key through a way they can reasonably verify required that Alice put that public key there.
Also, I want the file's current location/storage/transmission to not be required to prove the identity of Alice in any way. And, ideally, I'd like Alice to be able to authenticate, disconnect from the internet, and continue to be able to make provably-authored edits on her document.
I'm afraid I'm reinventing the wheel, but I cannot find any evidence that there are pre-existing APIs for doing this. This seems like a really basic set of operations; being able to sign data with identity, and verify it was that identity that signed it. I was somewhat surprised when I couldn't find an API to do this.
Embedding a link to a shared document that Alice has on her cloud storage, and having Bob go and fetch it to verify the signature, is one thing I'm considering; is there a way to have a stable URL with both of those storage providers that can be traced back to being connected to Alice?
Is there a better approach?
Alice must get document signing certificate separately from the office 365 or gsuite. It is possible to get simple and cheap certificate that shows that this e-mail address control has been verified.
If the private key is on the HSM like Smart Card or USB token then it is possible to get eIDAS approved or Adobe Trusted list CA signed certificate and signature validation is relatively easy.
It is also possible to setup your own CA and in this case you need to implement signature validation as well and make sure your own CA is trusted by Bob
I have a fundamental confusion about the public key cryptography in the Bitcoin (Blockchain) field.
For example, I understand that, in Bitcoin, when Bob wants to make a transaction, he sends out a transaction that contains the following:
The plain transaction message (such as Bob sends 5 Bitcoins to Alice).
Bob's public key
The digital signature of the transaction, signed using Bob's private key
I understand the whole Bitcoin network will validate this transaction based on Bob's public key and digital signature, which is broadcasted along with the plain transaction info all across the network.
However, what if the above transaction (that Bob sends Alice 5 bitcoins) is initiated by Eve? Eve broadcasts the plain transaction message, her public key, the digital signature signed using her private key. It seems the whole Bitcoin network will also validate the transaction based on the provided information.
Can you please clarify what type of wrong thinking I'm having?
Thanks a lot!
Cheers,
M.
Everything is correct. But, Bob cannot send any Public Key. He must provide the Pubkey, related to the address, from which he take 5 BTC for send further. In the Bitcon design, the address is hash of the Pubkey.
As result, Eve does not know pubkey for Bob's address, and she unable send transaction, which spends Bob's money. But, of course, she able to send transaction with pubkey for address, she owns. By other words, Eve can spend her own money, and this is OK.
If you will see details of the Bitcoin script, you will see typical spending script:
ScriptPubKey = OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG
This script duplicate pubkey, hashing one copy, compare hashed copy with btc_address, and if equal - checks signature. As you see, no any pubkey acceptable.
Context: I have a mobile app, and I don't have, and will not, implement a traditional authentication flow (email/pw, social login). Instead, I would like to leverage asymmetric key encryption.
Requirements: For the sake of simplicity, let's imagine a simple backend with one User model, which only has one field: favorite_number.
a user can CRUD a User model on the backend.
a user cannot CRUD another user's User model.
Potential solution:
Alice generates a private/public key pair on her mobile device. She keeps the private key securely on-device.
Alice makes a network request (let's say a RESTful POST request) to the backend, with the following payload:
{
"public_key": {Alice's public key},
"favorite_number": 42,
"signature": sign_with_private_key(42)
}
where sign_with_private_key(42) is the signature of the message 42, signed with Alice's private key.
The backend receives the above payload, verifies that the signature matches the public key and the favorite_number, and saves the following information in its DB (assume SQL below):
| public_key | favorite_number | signature |
| ---------- | --------------- | --------- |
| 0x... | 42 | 0x.. |
Alice wants to read her favorite number:
Alice sends GET /api/get_nonce?public_key={Alice's public key} to the backend
The backend looks in the DB the row with Alice's public key, and returns its signature column ONLY
Alice decrypts the signature with her local private key, it returns 42.
Bob wants to read Alice's favorite number, he calls the same endpoint GET /api/get_nonce?public_key={Alice's public key}, get's Alice's favorite_number signature, but cannot decrypt it.
Bob wants to modify Alice's favorite number, but cannot, because he can't compute the signature of the favorite_number message.
Caveats (which I can live with):
If Alice loses her phone or uninstalls the app, all her account information on the backend will be lost.
Additional assumptions:
The DB cannot be directly accessed by other party than the backend (and DB administrator) itself. (clarification request by #kelalaka). But that's independent of authentication.
Question: Is this authentication scheme viable? Do you see any big security loopholes?
This feels a bit over-complicated. If Alice has a keypair, then Alice can simply sign requests, and the signature is the authentication. There's no particular reason to sign individual pieces of data. Just sign the requests themselves. For example:
{
"request": {"message_id":123,"public_key":"...","favorite_number":42},
"signature": signature_of('{"message_id":123,"public_key":"...","favorite_number":42}')
}
It is critical that you sign everything that is part of the request.
Note that requests need to be single-use, otherwise this is not secure. By single-use, I mean that a timestamp should be in the request and the same request should not be useable more than once. You can also use a message counter (especially since you only have one device that can connect). So the server always rejects messages ids equal to or smaller than the last id sent for this user.
Your approach is vulnerable to reuse of the value upon another key. For example, I could reuse "42" and assign it to some other thing like "hated_number." Or I could replay this message and reset Alice's favorite number to 42 after she has changed it to something else. Signing the entire request is a much better approach and avoids a number of these problems (as long as a request can't be reused).
If Alice wishes to protect the data from the administrator, then she should encrypt the data with a symmetric key, but that's independent of authentication.
A simpler way to implement this, provided the transport is trusted, is to let Alice generate a random 256-bit identifier, and simply use that as the authentication. A 256-bit identifier will always be sufficiently sparse that it is unguessable (guessing the identifier is precisely the same as guessing an AES-256 key). With that, simply knowing the identifier is sufficient to authenticate a request. This only works if the transport is trusted, but that's the same as any static credential (username+password, token, etc). By a trusted transport, I mean HTTPS with pinned certs, for example, or any similarly encrypted and authenticated transport.
Is it possible to implement a login protocol with asymetric cryptography instead of the hashed password method?
For example, while creating an account, the client generates a private/public key pair from a hash of the username and password. The public key is then sent to the server with the username, and the server stores the username and the public key. When the user wants to login, he enters his password, the client regenerates the private key, signs a nonce with it, and sends the signed message to the server. The server is then able to authenticate the user as he knows the public key associated with the username.
Is there any flaws in this protocol?
And what would be the advantages over storing the password hash?
There might be a serious flaw with the authentication, yes, depending on the implementation. If Bob is the server and Alice is the client, with Mallory a malicious eavesdropper:
If Alice generates a random number, concatenates this with her username, encrypts with her private key and sends to server. Server decrypts and verifies with Alice's public key. Without the server saving the random number, this is susceptible to replay attacks - Mallory could just listen in, save the blocks that Alice sends to the server and just replay them later. Without saving them, the server would be none the wiser.
To protect the server against this, the server would have to generate the random number. It would also need to be a secure random number, otherwise Mallory could predict, or at least guess what the next number will be.
If Mallory could intercept messages, then he can purport to be Alice - he intercepts all communications and just relays them, even if the server generates the random number.
Alice and Bob both need to be able to prove that it was the other who has cheated. They also need to be able to detect tampering from Mallory - the protocol needs some extra layers to ensure authenticity of the messages.
There is research going into this at the moment, but as far as I know, it is very difficult to authenticate a user without a trusted certificate authority also being used: public keys can be known by all, but any attacker can swap their own public key for that of another without detection, unless there is trust established through a certificate authority.
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
What I understand about RSA is that Alice can create a public and a private key combination, and then send the public key over to Bob. And then afterward Bob can encrypt something using the public key and Alice will use the public and private key combo to decrypt it.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
Basically, the procedure is:
The client connects to the server and asks for the server's certificate. The certificate contains the public key and information about the server's identity.
Assuming the client is happy with the server's identity, it generates a random number P and encrypts it with the server's public key.
Only the server can decrypt P (with it's private key - not shared with anybody) so when the client sends the encrypted random number to the server, the server decrypts it.
The client and server both use P to generate a symmetric key for use in a symmetric encryption algorithm, safe in the knowledge that only the client and server know the value of P used to generate the key.
Alice will use the public and private key combo to decrypt it
Alice would just decrypt it with her private key.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it?
Alice would need Bob's public key to send something to him.
Typically, public key encryption is used for authentication, non-repudiation (like signing), and distribution of symmetric keys (which are faster for encrypting/ decrypting long messages).
Simple, you need a key.
SSL/TLS solves this problem by creating a symmetric session key during the connection setup. The public key cryptography is used to establish this session key, which is then used for bi-directional data communication. Read more about TLS
I didn't create this, but someone shared this video with me and it helped the theory make much more sense. As always the devil's in the details (implementation).
http://www.youtube.com/watch?v=YEBfamv-_do
On a general note I struggled to understand Public Key Cryptography for quite a while along with the other elements of PKI such as Digital Signatures and Certificates whilst preparing for Microsoft C# certification.
I came across an explanation in the form of a concise and detailed PDF at cgi.com. I know it's back to good old Alice and Bob! but it really cleared things up for me with its diagrams and notes and also has some thought provoking questions at the end. Definitely recommend it.
Visit http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
This is where you're wrong; you do have a private key. As part of the handshaking process, each side generates two keys: a public key and a private key. The client sends its public key to the server, who will use it to encrypt all data sent to the client. Likewise, the server generates both keys and sends its public key to the client, which will use it to encrypt all data sent to the server.
In many scenarios, the asymmetric key algorithm is used only to exchange another key, which is for a symmetric algorithm.
In this situation, Alice would use Bob's public key to encrypt the data and Bob would then decrypt it with his private key.
Essentially, a public key encrypts data and a private key decrypts that data. Since every user has both a public and private key, you can securely send data to any other user.
If you connect to the site of your bank it works a lot of cryptographic things. The most important is that you use public key of the bank to send a piece of information to the bank, because in every SSL (https) connection server send to client it's public key packed as a certificate.
Usage of certificate and world wide PKI is important. You want be sure, that if you gives to the bank your bank pin, that on the other side is really your bank and not an other person. This will be solved, because on every computers there are a small number of public keys of well known organisations (like VeriSign) and bank send you not only his server public key, but a certificate. certificate is a message signed by VeriSign for example, which say "this public key is really from the bank XYZ". So because you have public key of VeriSign you can first verify, that server certificate of the bank is correct. So you can be sure, that you communicate really with your bank.