Suppose there is a message that is signed using RSA and I want to verify the signature on a remote device.

The message is generated and then signed using the private key PRIV1. The following message is sent to the remote device : {message , PUB1 , Signature} The remote device then verifies the RSA signature using PUB1 and accepts the message. in order to prevent an adversary to generate its own message and sign it using its private key (lets call this pair PRIV2,PUB2) and then sending the same bundle : {message , PUB2 , Signature} which will be accepted by the remote device, most of the implementations use PKI in a form of a CA that issues a certificate for the public key.

I was introduced to a different public key verification approach , assuming the remote device is a sources limited embedded device that has a secured way to get a public key digest value from the device vendor (which is the only party sending the messages) and store it in a secured location and that most of the messages are signed with the same key- once a message is received the device will compare the stored digest to the digest of the public key in the message , if they are equal then it will proceed with the authentication and if not , it will abort the operation.

Under the given assumptions , does this scheme is as secured as using PKI in the form of CA issuing certificates for the public key ?

  • your scenario just changes where the CA is ... from a neutral 3rd party to your own local machine
    – schroeder
    Oct 29, 2017 at 14:07
  • 1
    Part of the whole "verify the signature" part is checking that the party using the key is the party they claim to be ... your suggestion acts just like a "web of trust" using yourself as the authoritative party. I'm not sure what you are trying to gain.
    – schroeder
    Oct 29, 2017 at 14:09

1 Answer 1


No, your "local trust" idea is definitively NOT as secure as the tried and tested PKI process that has been in place for decades and trusted by every major party globally requiring encryption.

For one basic reason: corruption of the local store. If a malicious actor can change the local store, then the local machine will trust anything. The whole point to a neutral 3rd party is to prevent this type of localised problem.

  • thank you for your comment. 1.It is not my idea , I saw this implementation on some 3rd party device 2.there is a way to make sure that corrupting the local store is not possible if you are using limited number of keys (e.g. OTP register blocks to store the digest) Oct 29, 2017 at 14:19
  • @DimaShifrin I think you are asking the wrong question. Is it "as secure as"? No. Not even close. "Is it useful?" Sure! But you need to perform a risk assessment to determine if the lowered security is OK in your implementation.
    – schroeder
    Oct 29, 2017 at 14:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .