tdiesler / nessus-didcomm

Nessus DIDComm is about Digital Identity and Verifiable Credentials
Apache License 2.0
8 stars 1 forks source link

Did Document verification may fail in DidEx Response #32

Closed tdiesler closed 1 year ago

tdiesler commented 1 year ago

An attached DidDoc in a DidEx Response sent by AcaPy is not signed by the owner of the Did within the Doc. Instead it is signed by whoever created the attachment. Is that ok?

A rough DidEx Responder could attach a doc with the did that he does not own.

CrossRef: https://github.com/hyperledger/aries-cloudagent-python/issues/2098

tdiesler commented 1 year ago

@TimoGlastra says ... https://discord.com/channels/905194001349627914/1066043270590894200

I think the verification we do in AFJ is to check both. So we check that the did document contains the key that is used to send the did exchange response. In addition if the key used is different than the key in the oob invitation, we require that the attachment is also signed by the invitation key. This is important so you know you're interacting with the did from the invitation)

Thanks

tdiesler commented 1 year ago

I looked at this more closely - here is what I found ...

DidExchange Request

When AcaPy sends a Request after receiving an Out-of-Band Invitation, it signs the attached Did Document with the key contained in that Document.

Specifically, it signs the Did Document with did:key:z6MkgnRbNmHJq8YGdtzxUxgqPkqAZ3qRWWFbntsST6D9CykA from jws.header.kid, which is the did:key representation of did:sov:5GzbVeQgVwc48ZcLzUkRdP

2023-01-30 09:49:55,947 INFO [main] o.n.d.p.RFC0434OutOfBandProtocol [RFC0434OutOfBandProtocol.kt:91] -- Invitee (Faber) received Invitation: {
    "@id":"e5e12f21-98d1-4e96-b0b2-5a633a1e325c",
    "@type":"https://didcomm.org/out-of-band/1.1/invitation",
    "label":"Alice invites Faber",
    "accept":[
        "didcomm/v2"
    ],
    "handshake_protocols":[
        "https://didcomm.org/didexchange/1.0"
    ],
    "services":[
        {
            "id":"#inline",
            "type":"did-communication",
            "recipientKeys":[
                "did:key:z6MknrV2etMBZJ87sUdgDS8xoBx5wt4ZasNqg8GVfUyit5JW"
            ],
            "serviceEndpoint":"http://192.168.0.10:8130"
        }
    ],
    "state":"initial"
}

2023-01-30 09:49:56,392 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:135] -- Recipient verkey: 9QDz4e6kDkdekynyXsB7x6Q68JniAz8Uz7MZqD1hxrX8
2023-01-30 09:49:56,393 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:146] -- Sender verkey: 3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn
2023-01-30 09:49:56,395 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:171] -- Unpacked Envelope: {
    "@type": "https://didcomm.org/didexchange/1.0/request",
    "@id": "195c50e9-cdf9-433f-910d-676b7a9029ca",
    "~thread": {
        "thid": "195c50e9-cdf9-433f-910d-676b7a9029ca",
        "pthid": "e5e12f21-98d1-4e96-b0b2-5a633a1e325c"
    },
    "did": "5GzbVeQgVwc48ZcLzUkRdP",
    "label": "Aries Cloud Agent",
    "did_doc~attach": {
        "@id": "96a9b48a-4b9c-4694-9952-c32e29546a2a",
        "mime-type": "application/json",
        "data": {
            "base64": "eyJAY29udGV4dCI6ICJodHRwczovL3czaWQub3JnL2RpZC92MSIsICJpZCI6ICJkaWQ6c292OjVHemJWZVFnVndjNDhaY0x6VWtSZFAiLCAicHVibGljS2V5IjogW3siaWQiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQIzEiLCAidHlwZSI6ICJFZDI1NTE5VmVyaWZpY2F0aW9uS2V5MjAxOCIsICJjb250cm9sbGVyIjogImRpZDpzb3Y6NUd6YlZlUWdWd2M0OFpjTHpVa1JkUCIsICJwdWJsaWNLZXlCYXNlNTgiOiAiM0xBWW5YMnNWYjNvWFFBRm9QaXpZZkhBalVaYTZkMUY2c3hXY3BGOEhreG4ifV0sICJhdXRoZW50aWNhdGlvbiI6IFt7InR5cGUiOiAiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsICJwdWJsaWNLZXkiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQIzEifV0sICJzZXJ2aWNlIjogW3siaWQiOiAiZGlkOnNvdjo1R3piVmVRZ1Z3YzQ4WmNMelVrUmRQO2luZHkiLCAidHlwZSI6ICJJbmR5QWdlbnQiLCAicHJpb3JpdHkiOiAwLCAicmVjaXBpZW50S2V5cyI6IFsiM0xBWW5YMnNWYjNvWFFBRm9QaXpZZkhBalVaYTZkMUY2c3hXY3BGOEhreG4iXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwOi8vMTkyLjE2OC4wLjEwOjgwMzAifV19",
            "jws": {
                "header": {
                    "kid": "did:key:z6MkgnRbNmHJq8YGdtzxUxgqPkqAZ3qRWWFbntsST6D9CykA"
                },
                "protected": "eyJhbGciOiAiRWREU0EiLCAia2lkIjogImRpZDprZXk6ejZNa2duUmJObUhKcThZR2R0enhVeGdxUGtxQVozcVJXV0ZibnRzU1Q2RDlDeWtBIiwgImp3ayI6IHsia3R5IjogIk9LUCIsICJjcnYiOiAiRWQyNTUxOSIsICJ4IjogIklxQTBoLVJEQTgxaWxuS0xuNnlaNWd5VU44RlRCODlHVlhRMFlTRU5ocDgiLCAia2lkIjogImRpZDprZXk6ejZNa2duUmJObUhKcThZR2R0enhVeGdxUGtxQVozcVJXV0ZibnRzU1Q2RDlDeWtBIn19",
                "signature": "RQzb5f1ds-Tv0tMe4meF7dM6iY2URpFeofshFRrVza6t8_6WJH6bTR2HtXismEpy2Ry2YEGm2Vu73Pv_dv-wAA"
            }
        }
    }
}

2023-01-30 09:49:56,398 INFO [XNIO-1 task-1] o.n.d.p.RFC0023DidExchangeProtocol [RFC0023DidExchangeProtocol.kt:193] -- Responder (Alice) received DidEx Request
2023-01-30 09:49:56,402 INFO [XNIO-1 task-1] o.n.d.s.DidDocumentService [DidDocumentService.kt:133] -- Extracted Did Document: {
    "@context": "https://w3id.org/did/v1",
    "id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP",
    "publicKey": [
        {
            "id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP#1",
            "type": "Ed25519VerificationKey2018",
            "controller": "did:sov:5GzbVeQgVwc48ZcLzUkRdP",
            "publicKeyBase58": "3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn"
        }
    ],
    "authentication": [
        {
            "type": "Ed25519SignatureAuthentication2018",
            "publicKey": "did:sov:5GzbVeQgVwc48ZcLzUkRdP#1"
        }
    ],
    "service": [
        {
            "id": "did:sov:5GzbVeQgVwc48ZcLzUkRdP;indy",
            "type": "IndyAgent",
            "priority": 0,
            "recipientKeys": [
                "3LAYnX2sVb3oXQAFoPizYfHAjUZa6d1F6sxWcpF8Hkxn"
            ],
            "serviceEndpoint": "http://192.168.0.10:8030"
        }
    ]
}

DidExchange Response

When AcaPy sends a DidEx Response as reply of a DidEx Request, it signs the attached Did Document with the invitationKey, instead of the key contained in that Document

Specifically, it signs the Did Document with did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3 from jws.header.kid, which corresponds to invitation.services[0].recipientKeys[0]

2023-01-30 10:17:18,631 INFO [main] o.n.d.p.RFC0434OutOfBandProtocol [RFC0434OutOfBandProtocol.kt:69] -- Inviter (Faber) created Invitation: {
  "@id": "44a79b7c-b900-4f58-be10-7f85c5524bc0",
  "@type": "https://didcomm.org/out-of-band/1.1/invitation",
  "label": "Faber invites Alice",
  "accept": [
    "didcomm/v2"
  ],
  "handshake_protocols": [
    "https://didcomm.org/didexchange/1.0"
  ],
  "services": [
    {
      "id": "#inline",
      "type": "did-communication",
      "recipientKeys": [
        "did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3"
      ],
      "serviceEndpoint": "http://192.168.0.10:8030"
    }
  ],
  "state": "initial"
}

2023-01-30 10:17:18,673 INFO [DidEx-0] o.n.d.p.RFC0023DidExchangeProtocol [RFC0023DidExchangeProtocol.kt:174] -- Requester (Alice) sends DidEx Request: {
    "@type":"https://didcomm.org/didexchange/1.0/request",
    "@id":"7f79736c-818a-4c72-a2b5-5690593ee7dc",
    "~thread":{
        "thid":"7f79736c-818a-4c72-a2b5-5690593ee7dc",
        "pthid":"44a79b7c-b900-4f58-be10-7f85c5524bc0"
    },
    "did":"9mknvxgt71rjecbd9qS6Zk",
    "label":"Invitee Alice",
    "did_doc~attach":{
        "@id":"adfa9e83-17d1-4b0f-881e-65c8f88320d9",
        "mime-type":"application/json",
        "data":{
            "base64":"eyJAY29udGV4dCI6Imh0dHBzOi8vdzNpZC5vcmcvZGlkL3YxIiwiaWQiOiJkaWQ6c292Ojlta252eGd0NzFyamVjYmQ5cVM2WmsiLCJwdWJsaWNLZXkiOlt7ImlkIjoiZGlkOnNvdjo5bWtudnhndDcxcmplY2JkOXFTNlprIzEiLCJ0eXBlIjoiRWQyNTUxOVZlcmlmaWNhdGlvbktleTIwMTgiLCJjb250cm9sbGVyIjoiZGlkOnNvdjo5bWtudnhndDcxcmplY2JkOXFTNlprIiwicHVibGljS2V5QmFzZTU4IjoiNW5Ia1VUQ0xZUjVheTQyYlZyNEE0NmRINjVrZ1h6VHg4endoWGtLVGhvMUYifV0sImF1dGhlbnRpY2F0aW9uIjpbeyJ0eXBlIjoiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsInB1YmxpY0tleSI6ImRpZDpzb3Y6OW1rbnZ4Z3Q3MXJqZWNiZDlxUzZaayMxIn1dLCJzZXJ2aWNlIjpbeyJpZCI6ImRpZDpzb3Y6OW1rbnZ4Z3Q3MXJqZWNiZDlxUzZaaztzcnYiLCJ0eXBlIjoiTmVzc3VzQWdlbnQiLCJwcmlvcml0eSI6MCwicmVjaXBpZW50S2V5cyI6WyI1bkhrVVRDTFlSNWF5NDJiVnI0QTQ2ZEg2NWtnWHpUeDh6d2hYa0tUaG8xRiJdLCJzZXJ2aWNlRW5kcG9pbnQiOiJodHRwOi8vMTkyLjE2OC4wLjEwOjgxMzAifV19",
            "jws":{
                "header":{
                    "kid":"did:key:z6MkjEYo4hSmsxa45YsJBR1zuCBGuf2XwsiJq1rdN2HUd1nd"
                },
                "protected":"eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDprZXk6ejZNa2pFWW80aFNtc3hhNDVZc0pCUjF6dUNCR3VmMlh3c2lKcTFyZE4ySFVkMW5kIiwiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiUndqU3FDNUc1d2ZXX3JyYkRSVVNCNWhHMXI4TW05MTRYWm95S1c2d28yWSIsImtpZCI6ImRpZDprZXk6ejZNa2pFWW80aFNtc3hhNDVZc0pCUjF6dUNCR3VmMlh3c2lKcTFyZE4ySFVkMW5kIn19",
                "signature":"kMnjG7WtXsX4NqPPK4kqIVQ1qJfzprDeruJe9B7OW1QOEzt_bUIlhrS6T_CFgZHcvVMnCv-p1w6U26Mz-evMAw"
            }
        }
    }
}

2023-01-30 10:17:19,260 INFO [XNIO-1 task-1] o.n.d.p.RFC0019EncryptionEnvelope [RFC0019EncryptionEnvelope.kt:171] -- Unpacked Envelope: {
    "@type": "https://didcomm.org/didexchange/1.0/response",
    "@id": "5d7b609b-d93f-478c-bbcc-0405cce72103",
    "~thread": {
        "thid": "7f79736c-818a-4c72-a2b5-5690593ee7dc",
        "pthid": "44a79b7c-b900-4f58-be10-7f85c5524bc0"
    },
    "did": "8M7v4PMd8mgYUCTUJRyS3C",
    "did_doc~attach": {
        "@id": "455c55ea-b407-4289-bb28-e0880fada760",
        "mime-type": "application/json",
        "data": {
            "base64": "eyJAY29udGV4dCI6ICJodHRwczovL3czaWQub3JnL2RpZC92MSIsICJpZCI6ICJkaWQ6c292OjhNN3Y0UE1kOG1nWVVDVFVKUnlTM0MiLCAicHVibGljS2V5IjogW3siaWQiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDIzEiLCAidHlwZSI6ICJFZDI1NTE5VmVyaWZpY2F0aW9uS2V5MjAxOCIsICJjb250cm9sbGVyIjogImRpZDpzb3Y6OE03djRQTWQ4bWdZVUNUVUpSeVMzQyIsICJwdWJsaWNLZXlCYXNlNTgiOiAiNTFGVUJRaU5XS0drenl4b3o5S0t1WWhvWEE5d2IzUmI5SlpTQW16eURhekwifV0sICJhdXRoZW50aWNhdGlvbiI6IFt7InR5cGUiOiAiRWQyNTUxOVNpZ25hdHVyZUF1dGhlbnRpY2F0aW9uMjAxOCIsICJwdWJsaWNLZXkiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDIzEifV0sICJzZXJ2aWNlIjogW3siaWQiOiAiZGlkOnNvdjo4TTd2NFBNZDhtZ1lVQ1RVSlJ5UzNDO2luZHkiLCAidHlwZSI6ICJJbmR5QWdlbnQiLCAicHJpb3JpdHkiOiAwLCAicmVjaXBpZW50S2V5cyI6IFsiNTFGVUJRaU5XS0drenl4b3o5S0t1WWhvWEE5d2IzUmI5SlpTQW16eURhekwiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwOi8vMTkyLjE2OC4wLjEwOjgwMzAifV19",
            "jws": {
                "header": {
                    "kid": "did:key:z6MkqopNJzgVesySmHK3YthpNvW4bWAKmcTW6kR1VoADjqn3"
                },
                "protected": "eyJhbGciOiAiRWREU0EiLCAia2lkIjogImRpZDprZXk6ejZNa3FvcE5KemdWZXN5U21ISzNZdGhwTnZXNGJXQUttY1RXNmtSMVZvQURqcW4zIiwgImp3ayI6IHsia3R5IjogIk9LUCIsICJjcnYiOiAiRWQyNTUxOSIsICJ4IjogInFMUzRScHBBeTNuZUdVNThjTHo2MGcyaVE5WUN4ZU04YTA1aXl5OGRwR1EiLCAia2lkIjogImRpZDprZXk6ejZNa3FvcE5KemdWZXN5U21ISzNZdGhwTnZXNGJXQUttY1RXNmtSMVZvQURqcW4zIn19",
                "signature": "LV-t-QUyCvYnh1C_VXMYkfX-Q-BRprpOy3kq47HVTMhmFOkrzEPHl9JN0TxkYsmXnGsCifdOBIVrQYSu8gBtCg"
            }
        }
    }
}
TimoGlastra commented 1 year ago

When AcaPy sends a Request after receiving an Out-of-Band Invitation, it signs the attached Did Document with the key contained in that Document - it does NOT sign it with the invitationKey

This is expected. The requester is not the inviter and therefore wouldn't be able to use the invitation key

When AcaPy sends a DidEx Response as reply of a DidEx Request, it signs the attached Did Document with the invitationKey, instead of the key contained in that Document

There's been a lot of ambiguity around this, but as I understand it, it ONLY needs to be signed if the invitationKey is different than the did document key. In addition, the key used to send the request/response message MUST match with a key inside the did document.

tdiesler commented 1 year ago

Thanks. Lets continue over here