Permission Artefact Verification on RFM using X509Certificate OpenSSL


#1

Hi,

I am new to this platform and I am able to do registration and download Permission Artefact. I was trying to verify the signed data from the artefact with signature and by extracting public key from x509 certificate.

I am using c++ and openssl for verification of code. The signed data is taken in a char pointer before verification process.

Also the signing and verification is working fine if the data is signed at my end using x509 Certificate.

Can you please share your side of implementation of x509 certificate verification using openssl using c.


#2

#3

Hi Sidbh,

I went through the repository and found the verification of permission artefact is being done through public key (.pem) file stored locally and not through public key extracted from X509 Certificate that comes with “permissionAretefact.xml”.
Is there a way I can verify the data inside “permissionAretefact.xml” with X509 certificate and signature inside it using OpenSSL. If yes can you please share some steps for same.

Thanks.


#4

Hi @cks123,
You don’t want to do that because then there would be no point of having a signature on the data.
Imagine if a third party creates the Permission Artefact, signs it using its own private key - you would be using the public key provided by the third party itself (from the certificate i.e. ), and will be able to successfully verify the Permission Artefact, when in fact, the Perm Art was not from DGCA.
You have to use a separately stored Public Key (which is released by Digital Sky) to verify the Perm Art.

Is that not right, @sidbh ?


#5

Hi sachman,

That not how verification of x509 Certificate works.

For your reference:
XMLSec Lib uses Intermediate and Root certificate for verification of signed XML:
https://www.aleksey.com/xmlsec/api/xmlsec-verify-with-x509.html#xmlsec-example-verify3

Even the DigitalSkyAPI java code uses similar process:

If we are signing it using x509 Certificate, it also need to be verified using same process.
Please let me know if I am wrong somewhere.


#6

Hi cks123,
When I said verification, I meant authenticity - my bad. Verification would basically mean checking the integrity of the message (XML data), something like a CRC check. But, what about the authenticity of the XML file - to affirm the Artifact is in fact generated by Digital Sky? This can’t be achieved by verifying the Permission Message for just integrity.

Reference, quoting from Page 47 of DGCA RPAS Guidance Manual:
The RFM service must
use the corresponding public keys (released by Digital Sky) to verify that the permission
artefact is released by authorised DSP and has not been tampered with during transport.
If the public key has to be changed (When Digital sky requests the Flight Module
Providers to change), the Flight Module Provider has to release a firmware update to
update the key.


#7

Hi sachman,

x509 Certificate signing ensures both verification and authenticity. The certificate that is used for signing permission artefact is signed by another CA Certificate to make it authentic.

Just to give you more clarity here’s a reference links:

May be @sidbh can give us more clarity on how he has achieved that.


#8

@sachman is correct, either a certificate or public key will be included in the firmware and should be immutable. The key would be provided during registration.


#9

Thanks @sidbh for responding.

We were able to successfully hit the Registration API, but we didn’t received any public key or Certificate in response.
Is it like that work is still in progress ?


#10

@charizard can respond to this, I haven’t reached that part of the implementation yet.


#11

Hey @cks123 yes the CA is still being set up by the authorities. If your NPNT compliance and everything else is done please reach out to @sid-ispirt and he should be able to help with the next steps


#12

Hi @charizard,

Thanks for clarity on status of the task.

Meanwhile, can the drone registration API send us self signed certificate in response? That will help us to complete the flow at our end. Later we can use the CA signed certificates.


#13

@cks123 the example artefact already has the signed certificate associated, that’s what I used for to verify the libnpnt implementation.


#14

@sidbh We have already went through the code and feel that’s not how the x509 certificate verification works. In the libnpnt implementation we are verifying the artefact with bundled signature and locally stored public key which is in “.PEM” format. I also understand that this PEM file might have been created from certificate.

If you look into DigitalSKy api(I have posted it before Permission Artefact Verification on RFM using X509Certificate OpenSSL), the service that is used to verify xml document(permission artefact in our case), it uses two certificates for verification.
That where I want to draw your attention. Let me know if we can go on call to discuss this further.

Also I want to avoid reworking hence if possible want to implement similar implementation as server side.


#15

Ok, I will have a look and revert back.


#16

@cks123 I have PM’ed you for a call. Pls check.


#17

@sidbh So, is there any change in the verification process which you have used in the libnpnt implementation?


#18

@sid-ispirt, Such information would be valuable publicly.


#19

@sachman yes, it seems so. I need to discuss with @charizard related to this, I will revert in the same thread with conclusion.


#20

There seems to be a need for maintaining a trusted certificate chain according to specs followed by server side implementation as pointed out by @cks123. I need to confirm on the process and example for the same.