2
$\begingroup$

I am building a SoC to capture and encrypt video at once. I would like to understand what encryption protocols are available to encrypt the video stream.

The video stream will be coming from a camera sensor, like a CCD. If necessary it can be pre-processed on the SoC into a particular format (for example to compress it) before being encrypted. It can also be encrypted from its RAW format if possible. The encryption protocol should have an efficient hardware implementation that can be implemented on SoC.

The goal of this embedded system is to achieve the highest possible security by reducing potential hardware or software attacks on the Soc that might expose the clear video stream to the attacker.

Note that this is a self contained chip, and the video data will not be sent over WiFi or network. It stays inside the chip.

$\endgroup$
  • 3
    $\begingroup$ I think we need more info to help you. Are you building your own hardware? What level of security do you need ("minimal", "enough" or "overkill"?) Usually "video stream" is not a stream but a series of packets (that can sometime swap positions due to internet routing) so also knowing how do you plan to send the data would be nice (internet, local wifi or cable?) Will the receiver also be custom and made by you? Encrypting RAW will not work because color CCD with 4Mpixels at 24 fps creates 288 Mbits of data per second. $\endgroup$ – Filip Franik Mar 1 '18 at 10:46
  • $\begingroup$ Thank you. This will be a completely embedded and self-contained system, like a SOC. The CCD/CMOS sensor generates the raw data, that I want to encrypt immediately. As for your comment about RAW data, I would be happy to encode it first to any format more suitable by using an on-chip encoder. The goal is to achieve highest security by reducing surface attack, i.e. clear video data is never transmitted over wire or WiFi, but instead it is immediately encrypted. As for security/encryption level, I need something that cannot be broken by modern computers and can be implemented in hardware. $\endgroup$ – Ventures Joe Mar 1 '18 at 14:29
  • $\begingroup$ Please put all those details (and everything else you think might be useful) into the question (by editing it), and not in comment. Will the data transfer be done by wire or WiFi or something else? $\endgroup$ – Filip Franik Mar 1 '18 at 15:33
0
$\begingroup$

I am building a SoC to capture and encrypt video at once. I would like to understand what encryption protocols are available to encrypt the video stream.

Building tiny SoC? Are you sure you're not using a SoC on a larger board like a pi? Do you have video compression acceleration?

The video stream will be coming from a camera sensor, like a CCD. If necessary it can be pre-processed on the SoC into a particular format (for example to compress it) before being encrypted. It can also be encrypted from its RAW format if possible. The encryption protocol should have an efficient hardware implementation that can be implemented on SoC.

For performance, you'll want hardware AES. Although you could use AES-GCM, this will require GHASH in hardware for performance; instead you can ignore GHASH and use a parallel block cipher based MAC instead, such as PMAC.

The goal of this embedded system is to achieve the highest possible security by reducing potential hardware or software attacks on the Soc that might expose the clear video stream to the attacker.

So far we have AES-PMAC; which makes a fine AEAD, although you ask for higher security so lets add nonce-misuse resistance. Accidental nonce-misuse may occur in many ways, including but not limited to: power faults, wrapping the counter, or incorrectly handling backup and recovery. I recommend you use AES-PMAC-SIV.

Encrypting raw uncompressed video does not leak anything assuming the raw size is constant. Encrypting compressed data can leak for instance the presence of motion in the video stream.

In either case, you should chop the video stream on segment borders such that no segment crosses multiple ciphertext messages. We now have an unbounded stream of variable-length messages to encrypt. You may use the OAE2 construction family to maximize nonce-misuse resistance. Use CHAIN to force sequential decryption, or STREAM to enable out-of-order decryption. The latter is ideal for video, as it enables seeking and does not rely on previous blocks (critical if you want to use the disk as a ring-buffer).

Note that this is a self contained chip, and the video data will not be sent over WiFi or network. It stays inside the chip.

If the data never leaves the disk, why are you encrypting the video stream instead of using full disk encryption (LUKS, LUKS2)?

If you'd like to restrict the lifetime of the video stream you can rotate the keys and treat your storage device as a large ring-buffer. This way you never need to waste time zeroing out the disk, which doesn't work well because the HDD or SSD is making sectors inaccessible while managing hardware errors and wear leveling.

Keys should only exist in memory and/or on a HSM.

Miscreant is the only library I've seen to offer AES-PMAC-SIV and OAE2 so far.

Pseudocode in Rust:

let mut file = File::open("video-dump", append);
let mut segments = record_camera();

let key = random();
let mut stream = Stream::new(key, nonce);

for seg in segments {
    file.write_all(stream.encrypt(seg, authenticated associated data))?
}

Notice the safe and simple interface. You do not need to mess with any raw ciphers. However, you'll want a header per message with the length of the segment and a flag for the start of a new stream and a flag for the end of a stream (if it ends peacefully).

$\endgroup$
  • $\begingroup$ To close a stream use stream.finish(message, aad) to eliminate length extension attacks. We know who encrypts; but who decrypts? Does this device have a monitor attached or is the disk removed? $\endgroup$ – cypherfox Mar 3 '18 at 14:29
  • $\begingroup$ Yes, I would be using the SoC as part of a larger system. Basically an ASIC on a board together with whatever else I will need. $\endgroup$ – Ventures Joe Mar 4 '18 at 18:39
  • $\begingroup$ Yes, I would be using an ASIC on a board together with whatever else I will need. I have not planned for video compression acceleration, but I could add that as well on the ASIC. With regard to AES, wouldn't it be susceptible to an attack on the semiconductor package, where an actor could capture the encryption key and use it to decrypt the data? I was thinking to use an asymmetric algorithm, so I would only have to store the public key inside the ASIC. I appreciate that RSA is not an option due to poor efficiency. Would you have a suggestion? $\endgroup$ – Ventures Joe Mar 4 '18 at 18:47
  • $\begingroup$ You don't necessarily need GHASH support in hardware, but instructions that can be used to efficiently implement GHASH are useful (e.g. the CLMUL extension). For example, pclmulqdq (perform carry-less multiplication quadword to quadword) which operations on a pair of 64-bit (quadword) polynomials over the finite field $GF(2^{k})$. This isn't like AES-NI which actually implements the algorithm in hardware. Instead it just accelerates expensive operations that are used in GHASH. $\endgroup$ – forest Mar 7 '18 at 4:03
  • $\begingroup$ Related to your account notes — To merge your accounts, please use the contact form at stackoverflow.com/contact and select I need to merge user profiles while providing things like login emails etc. $\endgroup$ – e-sushi Mar 7 '18 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.