8 ms·

Couldn't this be bypassed by regulating a drone's bitrate to a constant steady flow? The sacrifice will be either video quality or freshness of data, but it wou

by wyc 9y ago

Couldn't this be bypassed by regulating a drone's bitrate to a constant steady flow? The sacrifice will be either video quality or freshness of data, but it would be a straightforward way get past that protection.

oreo81 9y ago
Yes, just like anything...but it comes with a trade off.
ucaetano 9y ago
Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.
- Drakim 9y ago
  So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?
  - ucaetano 9y ago
    > Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video? Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested. Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless.
    - Roujo 9y ago
      > Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless. If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.
      - ucaetano 9y ago
        The average doesn't really matter. The researchers are looking for "steps" in data streamed caused by changes in the video. If you're adding random levels noise it will drown the signal that the researchers are looking for.
        jamiek88 9y ago
        But you are still open to a timing attack, no? The random noise becomes the background and unless it is a constant addition of noise (which wouldn't save any bandwidth, might as well use uncompressed stream) you could still time changes in the signal.
        Confiks 9y ago
        The 'solution' of adding random data to hide these "steps" is a common misunderstanding of the theory behind preventing bandwidth side-channel attacks. It'll probably work in practice as long as the amount of randomness relative to the delta is sufficiently large and the attacker only can only make a limited amount of samples.
    - Hupriene 9y ago
      All that would do is increase the number of intervals that would need to be observed. Adding noise to a channel only reduces the bandwidth of the channel.
      - totalZero 9y ago
        I could be wrong, but I don't know if that is true here. First, if the receiver is aware exactly what parts to ignore, and the transmission itself is not interfered with or altered, then it's not really noise as far as the channel is concerned. Second, the assumption here is that spurious packets would be sent when data is not being transmitted, so this principle probably wouldn't hold anyway because the "noise" is inversely correlated to the signal.
        Hupriene 9y ago
        1. The receiver here is the person determining whether or not they are being spied on. Not the user of the drone. 2. In order to make the real spikes fit into your random pattern you'd need to be able to predict when they will happen.
        totalZero 9y ago
        You are forgetting that the user of the drone can set the transmission protocol beforehand, and thus is still an important part of the process. Given that you have a channel between A and B and an eavesdropper C: Transmission between A and B can be done by any of several obfuscatory protocols, where (for example) a certain flag sent by A tells B to ignore some component of the transmission, to do no error correction on that part, etc. That flag is sent when updates are sparse, and filler (which is to be ignored) is added by B. Without determining how to identify between filler and data, C sees no variations in traffic volume. Overcoming real-time spikes is easy with this protocol. Just keep a buffer of a few seconds before you begin transmitting. This approach is a common answer to any sort of traffic analysis. There's actually a Tor alternative that operates on this principle of constant traffic between nodes (traffic analysis is an effective attack versus Tor), but the name escapes me at the moment.
    - nullbyte 9y ago
      It takes more CPU and battery to compress the video than to leave it raw. So sending a lossless or semi lossless version of the video should theoretically work.
      - yyzhero 9y ago
        wireless transmission costs magnitude more then CPU cycles hence delta frames.
    - electrograv 9y ago
      These are opposite things: > Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage > Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data You cannot simultaneously reduce network bandwidth and also increase it. Of course padding with noise increases bandwidth, but it's silly to do that when you could instead be padding it with more bits relevant to the video stream. The vulnerability here isn't inherent to video compression; it's that the compression rate (and therefore network packet rate) is variable (so as to minimize global size of a video stream). It would not be that difficult to modify an encoder to guarantee fixed bit rate over whatever time chunk you want (depending on how many frames is tolerable to buffer before sending out), then send out those chunks at regular intervals.
  - tylerhou 9y ago
    It's very likely that the drone doesn't have enough bandwidth to send the raw video, so you need to compress.
- barsonme 9y ago
  You can't compress truly random data, though. I guess you'd have to sufficiently pad the stream with data that compresses to a constant bit rate.
  - Dylan16807 9y ago
    All you have to do is pad after compressing. It all looks the same post-encryption.
- ythn 9y ago
  > No sacrificing video quality or freshness required. Just drone battery life
- pjc50 9y ago
  Constant-bitrate codecs modes are what you want.
- rebuilder 9y ago
  A constant bitrate video codec seems much simpler, IMO.
princekolt 9y ago
Indeed. However, it is a very good practical example of why encryption alone doesn't do much. (If the attacker can measure your data stream, they can make statistical assumptions and pull a lot of useful data out without breaking the encryption).

by wyc 9y ago

oreo81 9y ago

Yes, just like anything...but it comes with a trade off.

ucaetano 9y ago

Or and even easier way: just have the drone fill up the stream with random data so that the data stream never goes "quiet" when the image is mostly unchanged. No sacrificing video quality or freshness required.

Drakim 9y ago
So you compress the video to a smaller size, and then fill in the bandwidth you saved with random data? Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video?
- ucaetano 9y ago
  > Why compress at all? Wouldn't just having a pixel perfect stream solve the same issue and give better quality video? Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage, especially if the radio channel is congested. Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless.
  - Roujo 9y ago
    > Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data, making any prediction from the observer useless. If it's actually random, wouldn't the average bitrate of "still scene + occasional random data" still be lower than "active scene + occasional random data"? Given enough samples, of course.
    - ucaetano 9y ago
      The average doesn't really matter. The researchers are looking for "steps" in data streamed caused by changes in the video. If you're adding random levels noise it will drown the signal that the researchers are looking for.
      - jamiek88 9y ago
        But you are still open to a timing attack, no? The random noise becomes the background and unless it is a constant addition of noise (which wouldn't save any bandwidth, might as well use uncompressed stream) you could still time changes in the signal.
      - Confiks 9y ago
        The 'solution' of adding random data to hide these "steps" is a common misunderstanding of the theory behind preventing bandwidth side-channel attacks. It'll probably work in practice as long as the amount of randomness relative to the delta is sufficiently large and the attacker only can only make a limited amount of samples.
  - Hupriene 9y ago
    All that would do is increase the number of intervals that would need to be observed. Adding noise to a channel only reduces the bandwidth of the channel.
    - totalZero 9y ago
      I could be wrong, but I don't know if that is true here. First, if the receiver is aware exactly what parts to ignore, and the transmission itself is not interfered with or altered, then it's not really noise as far as the channel is concerned. Second, the assumption here is that spurious packets would be sent when data is not being transmitted, so this principle probably wouldn't hold anyway because the "noise" is inversely correlated to the signal.
      - Hupriene 9y ago
        1. The receiver here is the person determining whether or not they are being spied on. Not the user of the drone. 2. In order to make the real spikes fit into your random pattern you'd need to be able to predict when they will happen.
        totalZero 9y ago
        You are forgetting that the user of the drone can set the transmission protocol beforehand, and thus is still an important part of the process. Given that you have a channel between A and B and an eavesdropper C: Transmission between A and B can be done by any of several obfuscatory protocols, where (for example) a certain flag sent by A tells B to ignore some component of the transmission, to do no error correction on that part, etc. That flag is sent when updates are sparse, and filler (which is to be ignored) is added by B. Without determining how to identify between filler and data, C sees no variations in traffic volume. Overcoming real-time spikes is easy with this protocol. Just keep a buffer of a few seconds before you begin transmitting. This approach is a common answer to any sort of traffic analysis. There's actually a Tor alternative that operates on this principle of constant traffic between nodes (traffic analysis is an effective attack versus Tor), but the name escapes me at the moment.
  - nullbyte 9y ago
    It takes more CPU and battery to compress the video than to leave it raw. So sending a lossless or semi lossless version of the video should theoretically work.
    - yyzhero 9y ago
      wireless transmission costs magnitude more then CPU cycles hence delta frames.
  - electrograv 9y ago
    These are opposite things: > Because compression reduces the amount of data that needs to be transmitted, reducing network and battery usage > Instead of filling the stream and having a constant stream size, you could just code the drone do add random bursts of data You cannot simultaneously reduce network bandwidth and also increase it. Of course padding with noise increases bandwidth, but it's silly to do that when you could instead be padding it with more bits relevant to the video stream. The vulnerability here isn't inherent to video compression; it's that the compression rate (and therefore network packet rate) is variable (so as to minimize global size of a video stream). It would not be that difficult to modify an encoder to guarantee fixed bit rate over whatever time chunk you want (depending on how many frames is tolerable to buffer before sending out), then send out those chunks at regular intervals.
- tylerhou 9y ago
  It's very likely that the drone doesn't have enough bandwidth to send the raw video, so you need to compress.
barsonme 9y ago
You can't compress truly random data, though. I guess you'd have to sufficiently pad the stream with data that compresses to a constant bit rate.
- Dylan16807 9y ago
  All you have to do is pad after compressing. It all looks the same post-encryption.
ythn 9y ago
> No sacrificing video quality or freshness required. Just drone battery life
pjc50 9y ago
Constant-bitrate codecs modes are what you want.
rebuilder 9y ago
A constant bitrate video codec seems much simpler, IMO.

princekolt 9y ago

Indeed. However, it is a very good practical example of why encryption alone doesn't do much. (If the attacker can measure your data stream, they can make statistical assumptions and pull a lot of useful data out without breaking the encryption).