问题
there are several components of my application, needs their communication secure in the sense Origin Verified. these components cannot share a common secret. So I have to opt for asymmetric key encryption. assuming I've two components A and B A sends some data F to B and B has to verify that it really came from A
A generates digest H of F with its private KeyA attaches A_pub, H to its request Parameters, sends F and declares origin/sender as A B verifies the digest H with the A_pub provided against F
apparently it looks Okay But if some other component V does the same with V_pub and claims itself as A, B still thinks the request came from A as this H is made with V_prv openssl verifies Okay.
I want to give protection against this attack of V
I am using ecparam secp112r1 to minimize key length. and keys are repeatedly changed.
-- EDIT --
A, B and V are application components identified by unique URI. Its currently intended to constraint secure page flow. e.g. you can assume A, B, V be urls What I want is Only A can procced to B and only B can proceed to C .... and I don't want to maintain a global/application wide session for that. so If B can just verify the origin of this link based on the special parameters A have passed to it in a state/session-less manner. and the more generic it can be the more reusable it will be to implement in other scenarios too.
Once I thought to maintain a checksums of A_pub in a trusted global storage. however I am afraid wouldn't that be an over engineering ?
another way comes in my mind is to query back the origin url regarding the public key. However I want to avoid that.
回答1:
This technique cannot verify the identity of the sender, only that the keys are a matching pair.
Typically, B would already possess some piece of trusted information that it can use to validate A's identity. The information is generally a copy of A_pub that it had previously validated, or that has been signed by a trusted third party, in which case B must have access to that third party's public key.
Without this additional information, B cannot verify the identity of A.
来源：https://stackoverflow.com/questions/9957562/openssl-phishing-v-claims-to-be-a