Signature size

[yohanboniface]

Signature is a requirement according to current French plans. Not every usage may use it, this is why it's better to make it optional.

Nevertheless, when used, it can have a very huge impact on the payload length, so we need to study all the possible options to reduce its size.

To investigate:

• other algorithms that may produce a smaller hash (we now use AES-CMAC, which produces a 32 bytes hash for a 24 bytes input payload)
• truncate the final hash: as far as I understand it, we may truncate the final hash (for example cutting it at 16 bytes) without compromising the security (one still needs to compute the whole hash when trying to brut force a signature)
• only send the signature once every x payloads
• send the signature in a separate payload

Also, given the crypto world moves fast, it's possible that the chosen algorithm will become obsolete at some point, and we will need to evolve to a new one, but this would certainly need a period of time where both algorithm (old and new) will be used. So we may need a more granular field than a boolean, to allow defining which algorithm is used. This may also allow more flexibility if some use case of this protocols want a leaker or stronger algorithm.

Thoughts?

[yohanboniface]

@ratzillas can you share the details of the tests you have made on real chips?

[darekzbik]

So far you are proposing 'hash' not a real signature. Approach with AES-CMAC (an other MACs) require to share a key (symmetric key). In my opinion some elliptic curve signature algorithm will be much better. Key size and signature size for ECC (elliptic curve cryptography) are much shorter than RSA/DSA and for this reason are much better for small devices. Processing of ECC is also much faster.

In my mind I have some from NIST approved algorithms let's say secp256r1.

[darekzbik]

Using asymmetric signatures allow you to use all existing concepts for requesting certificates, issuing certificates and handling revocation lists.

Additionally other drones (or gliders) are able to verify signature and reject when private key used for signature was compromised.

Client (Glider) side verification of MACs is not possible.

[darekzbik]

ECC can be computed on some general purpose CPU or hardware acceleration can be used. Just for example http://www.microchip.com/wwwproducts/en/ATECC108A . This chip supports p256 algorithm, cost of the chip is 0.5USD. Additional benefit in such case if possibility of keeping security keys inside the chip which will offer much higher security level.

[yohanboniface]

ECC can be computed on some general purpose CPU or hardware acceleration can be used. Just for example http://www.microchip.com/wwwproducts/en/ATECC108A . This chip supports p256 algorithm, cost of the chip is 0.5USD.

Sounds like a very interesting info! cc @ratzillas

@darekzbik here is a bit more info on the French law context signature investigation: https://drone.beta.gouv.fr/developers/signing/

Additionally other drones (or gliders) are able to verify signature and reject when private key used for signature was compromised.

Humm, that would need the drones to have an up to date database of all the public keys in the network, right?

[yohanboniface]

Quoting Paweł on this topic:

For drone position report there is a desire to authenticate the information sent on the radio. Every packet would thus be signed and this information would be 256-bit = 32-byte long. It is most likely impractical to transmit this amount of data with every packet as this would more than double the amount of data which needs to be transmitted on the channel. The proposal is to transmit only a part of the signature with every packet, say 32-bits = 4-bytes. It would as well be a different part every time. The part selection could be done for example based on the Time field of the packet thus on its lowest 3 bits. This way every packet could be verified with a good degree of probability. A wrong authentication would be spotted immediately.

[darekzbik]

@yohanboniface thanks for sharing to gov page. Paweł send me this link earlier. Using public key infrastructure will throw away half of concepts mentioned in https://drone.beta.gouv.fr/developers/signing/

If a drone/glider would like to know which signatures are not valid (stolen/compromised) it will need to fetch list of invalidated keys. So network connection or some other way of updating database will be required.

There are two possible solutions for delivering revoked keys OSCP which allows one by one verification of a single certificate or CRL.

More about PKI in next comment

[darekzbik]

Using PKI and crypto chip (HSM module)

players

1. Government agency
2. Drone pilot
3. Glider or plane pilot (someone who is in danger)

flow

Gov agency setup a Certificate Authority. Technically it means that some private key is generated and will be kept secure by agency. Such key will be used for signing certificate requests CSR

Let's assume that drone contain a HSM module. It can generate private key internally so that it will be not possible to get it out of a chip. HSM can prepare CSR (sign it) so drone owner can start initialisation process by entering typical certificate details like name, location .... CSR is signed by a module and displayed somehow to the owner of drone. Request should be send to CA (gov agency) where it will be verified (user details should be confirmed) and certificate should be issued and send back to the owner.

Owner should upload certificate to drone. Drone should verify that certificate is issued by a trusted CA (gov agency) and when it is fine it should allow to start drone engine. If certificate is forged drone should not work.

Flying drone should sign position packets by its private key. And additionally time to time drone should send copy of certificate so that ground stations and OGN, FLARM or other device is able to cache certificate and and verify certification path.

Glider pilots who would like to avoid false alarms from spoofed sources can get CRL list from CA and ignore packets signed by revoked keys.

... we can discuss it further if you wish. Also some work can be pushed to manufactures of drones.

[davidbgk]

ECC can be computed on some general purpose CPU or hardware acceleration can be used. Just for example http://www.microchip.com/wwwproducts/en/ATECC108A . This chip supports p256 algorithm, cost of the chip is 0.5USD.

Do you know how much time it takes for such a chip to sign a payload like our ones?

And additionally time to time drone should send copy of certificate so that ground stations and OGN, FLARM or other device is able to cache certificate and and verify certification path.

It would generate a pretty big payload, are we sure it won't saturate the network during particular events?

[pjalocha]

I try to formulate a packet structure like this (1 Word = 32-bits): Header: 1 word Position: 4 Words Signature: 1 Word CRC/FEC: 1 or 2 Words Total: 7 or 8 Words = 28 or 32 bytes.

and thus gave 32-bit for the signature. 32 bytes is maximum what can be handled by nRF905, this I understand is the requeirment ? We could thus select different part of signature each time based say on the low Time bits. So when Time is 00sec we send the first word of the signature, if Time=01 we send the second, etc. This way every packet is signed.

[darekzbik]

Speed should be sufficient for us. A little bit newer chip ATECC508A is able to sign doc in 300ms. See this benchmark https://www.wolfssl.com/docs/benchmarks/ and search for 508A. This benchmark is based SSL so processing time in the chip is only a part of it (probably the most important). Document size is not very important as signature is calculate for a checksum not for a whole document.

[darekzbik]

And additionally time to time drone should send copy of certificate so that ground stations and OGN, FLARM or other device is able to cache certificate and and verify certification path.

It would generate a pretty big payload, are we sure it won't saturate the network during particular events?

Single cert can be 600 bytes long. (I've just create self signed EC cert prime256v1). How much of it can be removed.

Probably propagating this details over different channel is a good option. For sure in case of asymmetric cryptography public keys can be delivered to all users and all ground stations and planes. In case of symmetric keys it is not possible.

[pjalocha]

I propose to use the XXTEA for signature generation. It would go like this:

1. The position (or other) packet is (1+4) 32-bit words = 160bits.
2. add current time and thus have now 6x32bit = 192bits.
3. encrypt with XXTEA using the 128-bit secret key stored in the drone
4. the result is still 6x32bit = 192bits => select a 32-bit part of it and use it as signature to be transmitted.

XXTEA is well established in the Flarms and runs on small 8-bit and 32-bit MCU's. XXTEA is well suitable for small block sizes and the encryption is done in place thus memory footprint is minimal. It can be done in few miliseconds.

Adding the current time makes the signature resistant to record-and-play strategy of creating false packets.

[snip]

Yes, including time in signature is also important to prevent replay of captured packet.

[darekzbik]

@pjalocha XXTEA has know vulnerabilities and it is not on the list of approved certificates. Please see FIPS_140-2 and try to find something which is considered secured. Initially mentioned algorithm AES-CMAC is approved by FIPS. Please see this Annex. AES-CMAC can be 128bits or 256bits. It is a lot for nRF905 chip and ISM band it is true and it is sad but you are not able to have short and secure signature at the same time.

[yohanboniface]

Yes, including time in signature is also important to prevent replay of captured packet.

Good point. Given the paylaod itself only contain the time of day, we otherwise would generate signed packets that could be replayed one every day.

[yohanboniface]

The more I think about the signature, the more I feel the protocol should make it first optional, but mainly upgradeable and configurable. Because French needs and agenda may not allow to build something generic soon. Because we may have other countries, other needs (gliders…), that would need the signature to be different with true arguments. Because cryptography is an always changing game, and algorithm that are good some day, are leaked some day after.

So in my opinion, we should focus our effort at this stage in finding a generic rule to pass the signature. Which means, as I see it:

• at least one field that defines which algorithm is being used (or None if no signature is passed); maybe saying "algorithm" here is already reductive, and this should be even more vague to say "French national signature" or "OGN signature" or… Of course, the challenge is we want to consume very little bits for this
• a rule for sending the signature: that may be max bytes to be used, or a separate dedicated payload, and/or some rules to truncate it as suggested by Paweł for example, etc.

[darekzbik]

@yohanboniface 'Singature type' can be a filed in a similar way as 'packet version' it is true. I guess that this spec will be used by manufactures of drones to build their tracking devices. I really would like to convince them to build a tracker which will be capable to perform cryptographic operations (AES for encryption or MACs and some kind of asymmetric cryptography). When the first version of protocol will not offer such possibilities it will be difficult to add it without changing hardware.

[optimaltracking]

2 very important items: -We can not prescribe any microcontroler. -it must be easy to crypt for any cheap microcontroler -the transmiter has no access to the net

[darekzbik]

@optimaltracking I'm not going to insist to use some uC. If you ask for some algorithm (let's say AES) drone produces can choose to use stronger CPU, or CPU with crypto or external secure chip. If you accept 8 bit Atmel without crypto chip it will be difficult to add it in the future.

Also you can specify requirement that key need to be stored in a secure way. It does not force drone manufacturers to use ATECC508 they can use HSM chip which offer the same functionality.

[pjalocha]

Important aspects I can see for the signature transmission:

If we decide on nRF905 compatibility then we can only sent up to 32-byte packets.

This points to three possible solutions:

1. use small signatures
2. send selected parts of large signatures
3. send a large signature as a series of packets

Giving significant losses of packets on the RF paths (lot of various reasons for this) the method 3. would need an additional packet loss correcting layer like Reed-Solomon code, in the simplest case sending one more packet which is the XOR or the other and so when one of the packets is lost the signature can still be recovered.

I am in favour of method 2. thus I would like to ask an expect on cryptography how is the security aspect affected when using htis method. In other words how the two cases compare:

1. we sign only every Nth packet and send this signature in full. Other packets are not signed.

2. we sign every packet and with every packet we send 1/N of the full signature.

What do we gain, what do we loose.

[pjalocha]

For the flexibility of the protocol: we could add the fields saying the version, revision, signature algorithm, what part is included, etc. The problem is that this take packet space, which is precious... thus the question is where to put this information:

1. If we transmit it with every packet then the data (like position) can be used immediately upon reception.

2. If we transmit it with the "information" packets which are sent, say, every minute then the data received can only be interpreted after one of these packets is received, which can take more than one minute as packets get often lost on the radio.

If an aircraft decides to upgrade its protocol then for some time its data can be interpreted incorrectly. This is a rare case and could be handled by specifying a timeout when the protocol version data experies and so the transmitter which changed the protocol version would not be allowed to transmit anything during this period.

I expect at least a 16-bit word would be needed to store the information about protocol, I try to give here a quick list of elements I can think about:

• protocol version
• protocol revision
• signature type
• signature algorithm
• signature transmission method: partial, full, alternative paths

[pjalocha]

Another way to approach the protocol upgrade would be change the SYNC sequence for packets carrying the new protocol. Then, the SDR receivers could still listen to both old and new and the drawback would be that the aircrafts with old and new versions could not talk to eachother until those with old version perform the upgrade.

[optimaltracking]

No because all the receivers will not be SDR based

[pjalocha]

Thus you foresee ground receivers which would be simply an RF chip + MCU and wired to internet ? This far the range of such solution we find to be much shorter than SDR receiver, but possibly this could be improved with some R&D.

[optimaltracking]

Thanks pjalocha for your comments. Can you comment more on SDR receivers compared to harware receiver. Are they better? more sensitive and higher range?

[pjalocha]

Is my comment here gone ?

I thought I wrote a reply yesterday: SDR receivers easily get to 50km and ranges up to 300-400km have been seen (with high antennas and high flying aircrafts/balloons). RF chip like RFM69 see range like 10km, and the range of nRF905 in Flarms is like 5-10km.

Sylwester has compared the sensitivity in the lab and he found 8dB difference between SPIRIT1 chip and the SDR receiver.

SDR receiver can be made much more smarter, as it can process the RF data in a very complex way, removing characteristic interference, selectively filtering, correcting multipath propagation, etc.

[davidbgk]

Is my comment here gone ?

No comment has been deleted so it's probably on your side (or a bug on Github?).

[pjalocha]

On the cryptography functions which could possibly be used for signatures:

SipHash: https://131002.net/siphash/siphash.pdf Speck by NSA: https://en.wikipedia.org/wiki/Speck_(cipher)