OT --US Military Drone Video Feeds Will Not Be Encrypted Until At Least 2014
Sam Wormley
--US Military Drone Video Feeds Will Not Be Encrypted Until At Least 2014
(December 19, 2009)
According to US Air Force officials, encryption of video feeds from the
US military's unmanned Predator and Reaper aircraft will not be complete
for at least five more years. Earlier this week, reports emerged that
Iraqi insurgents had managed to access the drones' unencrypted video
surveillance feeds with a piece of off-the-shelf software that cost less
than US $30. The military has known of the vulnerability for more than
a decade, but said the advantage of having the information the drones
provided outweighed the risk of unauthorized access.
http://www.washingtonpost.com/wp-dyn/content/article/2009/12/18/AR2009121804281.html
[Editor's Note (Pescatore): it has become popular wisdom to say that
today the "need to share" should trump the "need to know." This points
out why that is a dangerous philosophy for any information that should
not be shared with the those who don't have a need to know.
(Ullich): For a security professional, it is sometimes hard to
understand these decisions. But one has to keep in mind that security
isn't the goal here, but obtaining meaningful and timely intelligence.
Losing some of it to the enemy may be an acceptable risk, like for a
retailer, it may be better to lose a few customer records then shutting
down shop this week.
(Skoudis): This just feels really wrong to me. 5 years? And that's on
top of the 10 years they've known about the issue. There are crypto
modules readily available that can handle all kinds of streaming or
stored formats. Even if the video is analog (which is doubtful), there
are tons of different digitization tools available. Very curious
indeed.
(Schultz): Some individuals are critical that the vulnerability
described in the story has not been fixed and will not be fixed for
several years. Yet at the same time, the military has weighed costs
versus benefits and found that the ratio does not justify fixing this
vulnerability right away. This is the way things should work when it
comes to remediating vulnerabilities. ]
Bad Idea
Mike Jr
> From: The SANS Institute <NewsBi...@sans.org>
>
> --US Military Drone Video Feeds Will Not Be Encrypted Until At Least 2014
> (December 19, 2009)
>
> According to US Air Force officials, encryption of video feeds from the
> US military's unmanned Predator and Reaper aircraft will not be complete
> for at least five more years. Earlier this week, reports emerged that
> Iraqi insurgents had managed to access the drones' unencrypted video
> surveillance feeds with a piece of off-the-shelf software that cost less
> than US $30. The military has known of the vulnerability for more than
> a decade, but said the advantage of having the information the drones
>
> [Editor's Note (Pescatore): it has become popular wisdom to say that
> today the "need to share" should trump the "need to know." This points
> out why that is a dangerous philosophy for any information that should
> not be shared with the those who don't have a need to know.
>
> (Ullich): For a security professional, it is sometimes hard to
> understand these decisions. But one has to keep in mind that security
> isn't the goal here, but obtaining meaningful and timely intelligence.
> Losing some of it to the enemy may be an acceptable risk, like for a
> retailer, it may be better to lose a few customer records then shutting
> down shop this week.
>
> (Skoudis): This just feels really wrong to me. 5 years? And that's on
> top of the 10 years they've known about the issue. There are crypto
> modules readily available that can handle all kinds of streaming or
> stored formats. Even if the video is analog (which is doubtful), there
> are tons of different digitization tools available. Very curious
> indeed.
>
> (Schultz): Some individuals are critical that the vulnerability
> described in the story has not been fixed and will not be fixed for
> several years. Yet at the same time, the military has weighed costs
> versus benefits and found that the ratio does not justify fixing this
> vulnerability right away. This is the way things should work when it
> comes to remediating vulnerabilities. ]
Sam,
Use your head. If I was the man in the middle .....
--Mike Jr.
Ricky Raccoon
> > (December 19, 2009)
The video feeds are unencrypted because the info being transmitted is
bogus. The back channel, which IS encrypted, contains the actual live
video.
Further, deponent sayeth not.
Alan Browne
> What "vulnerability" has been demonstrated over the last ten years?
It's common to not let the other side know what you have on him.
Depending on the link from the drone, the video signals are easy to
difficult to intercept.
OTOH, a one time pad encryption (a one chip or one line of code solution
in the drone comms system with a very long (say 32 gigabytes +/- a
random few MB ea month) pad changed monthly would overwhelm the
abilities of current enemies until a more robust encryption system were
put in place. Distribution of the pads could be done with very strong
encryption, decrypted by the drone maintenance people and loaded onto
the system. A unique pad per aircraft.
In any case, it is still vestiges of cold warrior thinking v. an enemy
that assumes you can see him from the air or space and therefore
arranges to not be seen in a thousand places. Further, he can play
silly bugger red herring games getting you to bomb civilians for public
"support".
Moderate
"Alan Browne" <alan....@FreelunchVideotron.ca> wrote in message
news:OLGdnW89_6Izya_W...@giganews.com...
It would be pretty cool watching what the drone was seeing.
Until if flew over your house.
HIPAR
adversary's ability to timely respond to intercepted information. So,
tactically, drone targets probably cannot avoid the strike. The
remaining problem would be a visual record, usable for propaganda, if
the strike was directed at 'innocents'.
--- CHAS
mi...@sushi.com
wrote:
I seriously doubt you could do OTP for video. Think of direct sequence
spread spectrum communications. The hardest part is getting
syncronized. With OTP, getting synchronized would be difficult. You
would have to insert some sort of non-encoded framing bits with data
to indicate where in that huge code you should be.
The encryption doesn't have to be that strong, just better than what
they do now. The last thing you want is to lock something down so
tight that it might not be functional when you need it.
Wolfgang S. Rupprecht
Alan Browne <alan....@FreelunchVideotron.ca> writes:
> OTOH, a one time pad encryption (a one chip or one line of code
> solution in the drone comms system with a very long (say 32 gigabytes
> +/- a random few MB ea month) pad changed monthly would overwhelm the
> abilities of current enemies until a more robust encryption system
> were put in place. Distribution of the pads could be done with very
> strong encryption, decrypted by the drone maintenance people and
> loaded onto the system. A unique pad per aircraft.
Doesn't true OTP each up expensive keying material like there is no
tomorrow? From everything I've read, an OTP used twice isn't all that
much better than not encrypting. I'm pretty sure you can xor between
the two streams and you'd drop out the one time (two timing?) pad's data
and get the two superimposed pictures.
On the other hand, I can't believe there isn't an off the shelf AES chip
that can be used at video speeds.
-wolfgang
--
Wolfgang S. Rupprecht
If the airwaves belong to the public why does the public only get 3
non-overlapping WIFI channels?
mi...@sushi.com
S. Rupprecht) wrote:
Since I've read them all, I can't which James Bamford book covers
this, but the Soviets used a OTP twice and the NSA was able to read
the message.
For your reading list:
The Shadow Factory
Body of Secrets
Puzzle Palace
Throw in "Spycraft" if you are into this stuff.
Alan Browne
Very good point. I was also ignoring signal reliability.
Do an in the clear sync block on each frame including a random handover
word (a 32 bit pointer) to a position in the OTP for encryption so that
every frame begins at a different position in the pad. Frames that are
completely received will be clear, some will scramble in mid frame if
even a single bit is lost.
> The encryption doesn't have to be that strong, just better than what
> they do now. The last thing you want is to lock something down so
> tight that it might not be functional when you need it.
A one time pad meets that and can even suffer late delivery of pads to
the field - the header tells you which pad is in use.
There are encrypted airborne modems, just not many with the required
bandwidth that are small/light enough for even the mid size (Predator)
drones. (I maybe wrong on this, I've been outside of that area for a
few years).
Ed M.
> that can be used at video speeds.
>
> -wolfgang
Yes. Dr. Ingrid Verbauwhede's students at UCLA have published a
number of papers over the past several years on circuit designs to run
AES at speeds in the Gbps regime.
http://www.emsec.ee.ucla.edu/index.html
A paper published in April 2006:
"Area-Throughput Trade-Offs for Fully Pipelined 30 to 70 Gbits/s AES
Processors", http://www.emsec.ee.ucla.edu/pdf/2006tc_hodjat.pdf
Some products returned by a Google search with the keywords "aes" and
"gbps":
http://www.highlandcomm.com/aes/HLCT_30Gbps_AES_CORE.pdf
http://elliptictech.com/products-clp-20.php
Bruce Schneier states the more likely reason for avoiding encryption
-- the inconvenience of key management (same column, different
comments):
http://www.schneier.com/blog/archives/2009/12/intercepting_pr.html
http://www.wired.com/politics/security/commentary/securitymatters/2009/12/securitymatters_1223
mi...@sushi.com
wrote:
Just staying off commercial DVB would be a start. ;-) ENG uses a DVB
scheme, but in a different band. You don't read about intercepted ENG.
I suppose a simple block converter would enable OTS DVB to work for
ENG, but again, I haven't heard of it being done, and the US has no
shortage of geeks that would do this just for the challenge.
You may recall some guy designing his own SPASUR receiving scheme to
detect signals from "the fence." I'm having trouble finding this on
google, but I recall the story quite well. My recollection is the DoD
invited the person to give a talk on how he designed this hardware.
Anyway, my point is the geeks are out there.
Alan Browne
> You may recall some guy designing his own SPASUR receiving scheme to
> detect signals from "the fence." I'm having trouble finding this on
> google, but I recall the story quite well. My recollection is the DoD
> invited the person to give a talk on how he designed this hardware.
> Anyway, my point is the geeks are out there.
The issue is not invention. This problem comparatively trivial wrt the
military's secure communications. What is never trivial is
implementation within a logistics and operational framework. That makes
it harder to implement quickly. It is compounded when special projects
are in place to get platforms in-theatre quickly and so a mishmash of
military stock and COTS hardware is cobbled together (by geeks and
others) without compliance to secure communications requirements. Then
it is a round peg in a square hole problem and takes longer to work out.
For that matter, nothing will slow down a development program like
secure communications which itself hobbles development due to security
requirements during development and in production. It can be quite
complex and legally demanding. This does not fit the geek workstyle
well. It's plodding program/project engineering instead.
Terje Mathisen
> I seriously doubt you could do OTP for video. Think of direct sequence
> spread spectrum communications. The hardest part is getting
common favorite the gps sats does this 1023 times. Each sat has a unique
sequence of those 1023 bits. If you want to use DSSS as an encryption
technique then your spreading code becomes your encryption key, but with
the limitation that an aggressor don't need to determine all of the bits
in order to decode the signal, just a large majority of them.
> syncronized. With OTP, getting synchronized would be difficult. You
> would have to insert some sort of non-encoded framing bits with data
> to indicate where in that huge code you should be.
videos you are watching?
Of course there are framing bits which are known, and can be used to
synchronize with the stream, that is both perfectly OK and as designed!
You encrypt the payload, not the envelope surrounding it.
Using DSSS is mostly orthogonal to this.
> The encryption doesn't have to be that strong, just better than what
> they do now. The last thing you want is to lock something down so
> tight that it might not be functional when you need it.
Tactical (war theater) security, which only needs to be good enough to
keep things secure for some hours to days, and
Forward security: Often you would not like an enemy to be able to
capture the encrypted stream and then some time in the future become
able to decode it and work out exactly what you were looking at, this
requires orders of magnitude stronger encryption.
Using something like AES256 with a per-session unique key would ensure this.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"