Media signing - Cryptographic information and certificate chain with packet loss.

[jcbeaulieu]

Hello,

In Section 5.7.3 of the specification, it is mentioned that the cryptographic information that defines the algorithms are only sent once.
It is also mentioned that the certificate chain is either sent once and at an arbitrary cadence. It is not clear whether or not it is the device that chooses this cadence, but I believe that is the case. Is this correct?

I see two potential issues with this approach.

1. If there is packet loss when receiving the cryptographic information or the certificate chain, the client would have no way of validating the stream.
2. Since this information would only be present at the start of a stream, this could pose challenges for data retention policies, where a client is expected to delete any media older than X days. If the stream is long lived, it would be possible for the client to "lose" the cryptographic information and certificate chain. Expecting the client to modify the stream itself by adding the certificate chain at the beginning of the video stream may be error prone and lead to loss of integrity if implemented improperly. For example, if the certificate is changed on the device, the client may embed the wrong certificate at the wrong time. If the client embeds the wrong certificate, the file which would valid now fails validation.

The ability for the client to request the cryptographic information and certificate chain similarly to key frame requests could help alleviate these issues.

Additionally, could the media signing SEI frames be disabled using ONVIF for networks with stringent bandwidth constraints?

Thank you,
Jordan

[bjornvolcker]

Thanks Jordan for valuable insights. They are very much appreciated.

Since the specification has been written during a long period of time, some things have changed during the process and the specification is in some places poorly formulated.

Regarding the difference between "Once or every document" and "Once or at any arbitrary cadence". Before adding the start-of-stream-SEI (golden-SEI) concept, we thought it could be good to lower the bitrate by sending certificates now and then (arbitrary cadence). Sending information at a different cadence is something we have in Axis Signed Video, but it makes life difficult for the client and the code in on the validation side. When exporting to file, vital SEIs could be missing. Then the concept of golden-SEIs is better and more robust (if we do not account for potential packet losses). I will replace "at any arbitrary cadence" with "every document".

Packet losses
It is true that packet losses in SEIs can ruin the feature. At this point the best one can do is to use retransmission I guess.

Data retention time
I have limited experience in clients, but I assume a video stream is not stored as one single huge file, but split into smaller files. Then the client should copy the golden-SEI to each file, so they can be validated individually. Then removing files when retention time pass cause no issue. Of course, the client can store the golden-SEI separately and add it when a file is downloaded, for which the golden-SEI should not be subject to any retention time. It is associated with the stream and not the storage. I agree that how this golden-SEI is treated by the client is probably the weakest link in the complete chain of validating a signed video.

New certificate on the camera
Can a stream live across a certificate change? This is a very good question. If the device continue to operate as normal while the certificate(s) change this is a potential problem when a stream is alive for a very very long time. I will discuss this with Axel. If it can happen, the device need to send a new golden-SEI (if the device uses it) when it happens.

Request cryptographic SEI
I like the idea of requesting golden-SEIs, but I think it is out of scope for the first version.

Disable SEI-frames
The media signing is disabled by default, if that's what you're going for. But if you mean "disable SEI frames for a while" in an ongoing stream it is not feasible. You could make life a little nicer for the video data by excluding SEIs and hence lower the bitrate some, but from a validation point of view there is no difference. But my gut feeling says that this is not what you're talking about.

[jcbeaulieu]

Thank you for your answer Bjorn,

For the enabling or disabling of SEI frames, in the wsdls, I see ways to check whether media signing is supported and ways of changing the signing certificates to use, but do not see a way to enable or disable the SEI frames. How would a client enable media signing?

Also, is there a way for the client to know whether a client would send information "once" or "every document" before starting the stream?

Thank you,
Jordan

[bjornvolcker]

In the Video Encoder Configuration a new field "Signed" is added to enable Media Signing.

Whether a SEI is sent "once" can be identified when received.

[bjornvolcker]

Regarding "new certificate" on the camera. When we read the ONVIF security specification one can not replace a certificate without terminating the existing one first, hence the stream has to be stopped and the restarted. In such a case, the new stream will need to transmit a new start-of-stream-SEI by definition.
From what we can see though, the security specification does not cover adding a new certificate. If the camera now can chose to use the new one, that can equally well be interpreted as replacing the other one for which the other certificate should be terminated and the stream should be stopped and restarted. Hence, media signing works.