Digital photos for forensic evidence

On 29 Jan 2006 09:43:42 -0800, Paul Rubin
wrote:

(Al Dykes) writes:
The chip that has the private key is in epoxy and designed to self
destruct when opened.

This is what you're missing. The chip with the private key has to get
the image from somewhere. How is it supposed to know that the image
that it gets is authentic? The whole camera has to be in epoxy, not
just the signing chip, or else the camera can be modified to present a
fake image to the chip for signing, and get a good signature.

Not necessarily. Just the entire imaging subsystem including the
sensor, the camera's CPU(s), and the hardware that does card I/O.
Actually, it seems a bit hard to imagine a sensor doing its job if it
is fully encased in epoxy.

Then there's also the possibility of displaying the fake image on a
sufficiently high-res monitor and photographing it with the "trusted"
camera. That's probably detectable with some effort, for now. Will
it stay that way? Who knows.


You have described the weakness in Digital Rights Management for say
movie downloads. Yes, it is possible to create a trusted path (à la
Next Generation Secure Computing Platform or MS Vista) so that the
downloaded movie can be shown only on trusted hardware that will
prevent unauthorized digital copying. But what is to prevent someone
from "filming" that movie and distributing copies of that "film?"

Father Kodak

Anyone consider Schneier and Kelsey's work on secured logs as
potentially relevant to this problem? See:
http://www.schneier.com/paper-secure-logs.html

(A keyed MAC is used to cover each encrypted log entry along with a
"running hash," and that hash is updated by hashing the current
encrypted data into the old hash value. This could prove that a
sequence of photos was not tampered with. If that was integrated with a
strong authentication from the officer using the camera, wouldn't that
provide evidence as strong as the sworn testimony of the cop. Could
this be a partial solution?)

Several references to RSA's SecurID token, earlier in this discussion,
caught my attention. It's a bit OT for any thread but this one, but it
is also an interesting case-study of the attack/defense rhythm in
InfoSec, which might usefully inform this discussion. Far warning: if a
discussion of the SecurID's integrity bores you, skip this.

Al Dykes , a fellow believer, wrote:

Making the chip tamperproof and self-destructing is standard practice. Lots of us
have carried SecureID cards... that generated a new pseudo-random number
every 60 seconds that is part of the login sequence to some computer system
that, in my case, was managing billions of bucks, at BigBank. [...]

Actually, the design goal for the SecurID was to make it
tamper-resistant and tamper-evident -- so that a SecurID token, if
opened, will likely show damage that the user, or any casual observer,
can see.

Paul Rubin, a skeptical soul, pointed out "tamper-proof" in hardware is
all relative. True enough, so far as it goes. It's been obvious for at
least a decade that it's very difficult to guarantee that any
processing platform, big or little, will be both always "reliable" and
always "closed." RSA's SecurID is, AFAIK, the only one-time password
(OTP) token that was redesigned to resist DPA and other "side channel"
attacks on its internal circuit -- but it is today a given that all
processors leak some information.

(InfoSec 101: Perfect security, unfortunately, is only available at
infinite cost. In the real world, where we use layers of imperfect
security, security metrics are always relative. Cryptographers
understand this better than most, since they design ciphers with a
target goal the is defined by the amount of work [brute force search of
the solution space] required to break them. Shortcuts, when found,
typically allow a more efficient brute force search of the solution
space or redefine the size of the solution space to be search. Usually,
that means either the design or its implementation is flawed. Such
attacks -- probably inevitable as our understanding of the technology
evolves -- generally make the attack more efficient, but not
necessarily feasible.)

Mr. D. wrote

The manufacturer has demonstrated to the satisfaction of lots of
important and serious people that it's impossible to take one of these
apart and decode it so as to predict the number series.

Say rather that RSA -- for which I've been a consultant for nearly 20
years -- has been rigorous in its design, proactive in meeting evolving
threats, and lucky. Four years ago, the original 64-bit SecurID --
with its 15 year-old proprietary Brainard hash -- was replaced by an
128-bit AES-based SecurID designed to provide additional functionality,
increase security, and block new and nascent threats.

Paul replied to Mr. Dykes:

Means of breaking SecureID cards have been known for many years.
http://www.homeport.org/~adam/dimacs.html describes a software attack.
See Anderson's book for general info on hardware attacks (maybe not
SecureID specific).

With all due respect, Paul, this is a rash claim, irresponsible if you
are an IT pro. While it is true that Anderson's use of forced glitches,
and Kocher's brilliant exploitation of leakage with "side channel"
attacks, revealed widespread vulnerabilities in almost all embedded
crypto implementations a decade past, that is not the same thing as
saying those vulnerabilities were actually exploitable.

RSA -- because of the widespread use of its crypto SDK -- was, as you
probably know, prominent in the effort to re-engineer installed crypto
to block or mitigate these threats. The 128-bit AES-based SecurID was
designed to confound or mitigate several new classes of potential
attacks on both its crypto and its hardware implementation.

I hesitate to appeal to irrelevant authority, but that seems inevitable
when discussing crypto. Mr. Dykes is certainly correct to note that, in
both Singapore and D.C., a lot of smart and crypto-savvy people have
confidence in the SecurID. All White House staffers carry one, as do
all US Senators.

Ultimately, of course, any security mechanism can be defeated by some
combination of work, access, indifference to detection, special
knowledge, and time (WAIST). Which is not the same thing as saying
that, say, an hardware attack to retrieve a SecurID's secrets would be
feasible -- given the defenses now built into the token -- or rational,
given less costly alternatives avenues of attack.

Adam Shostack's 9 year-old paper, the "software attack" you cited, was
a different kettle of fish. This a nice analysis of a protocol flaw
that RSA had discovered and fixed, the year before, with a mandatory
server upgrade, in code that Adam had access to. There was no known
exploitation of the protocol flaw before RSA discovered and fixed it.

Father Kodak pointed out:

.. [...] AFAIK, the attacks on a SecurID depend on having a large
.. number of samples from one card, which isn't often possible in
.. practice.

(Nitty-gritty: The most powerful theoretical attacks on the 64-bit
SecurID were described in a 2003 paper by Biryokov, Lano, and Preneel,
and a 2004 paper by Contini and Yin. Both teams leveraged collisions in
the old SecurID hash in a way that might potentially unlock the token's
secrets, given a very sample of large token-codes from one targeted
SecurID token. AFAIK, however, this approach never resulted in an
effective attack, despite numerous and extensive efforts to prove the
concept.)

The AES SecurID -- which RSA began shipping in January of '03 -- is
not vulnerable to the theoretical cryptanalytic attacks developed
against the old 64-bit SecurID. (While classic SecurIDs are still sold
on request, RSA has, for the past three years, also filtered the random
"seeds" embedded in 64-bit replacement tokens, to discard
collision-prone seeds.) Since most SecurIDs are replaced every 3 years,
routine roll-over has already hardened virtually all of the SecurID
user base. Of course, RSA, like Paul, has always insisted on the need
for two-factor authentication: both a SecurID token-code, inherently
resistant to replay, and a user-memorized PIN or password.

To the extent that extended footnote this is OT, I beg the pardon of
the List.

Suerte,
_Vin

Father Kodak writes:
The whole camera has to be in epoxy, not
just the signing chip, or else the camera can be modified to present a
fake image to the chip for signing, and get a good signature.

Not necessarily. Just the entire imaging subsystem including the
sensor, the camera's CPU(s), and the hardware that does card I/O.

That doesn't leave much ;-). See also:

http://web.archive.org/web/200310210....badgecam.com/

for an old attempt to make a secure camera, that a friend of mine was
involved with. I should have remembered this earlier. I wasn't
explicitly thinking of it earlier in the thread, but it was certainly
an influence. IIRC, the badge cam was supposed to be entirely potted
except for the lens, but it was a low resolution camera, not a general
purpose digicam. Its security measures had to be pretty serious,
given what it was supposed to protect against.

In article ,
Paul Rubin wrote:
(Al Dykes) writes:
The chip that has the private key is in epoxy and designed to self
destruct when opened.

This is what you're missing. The chip with the private key has to get
the image from somewhere. How is it supposed to know that the image
that it gets is authentic? The whole camera has to be in epoxy, not
just the signing chip, or else the camera can be modified to present a
fake image to the chip for signing, and get a good signature.


Like any other secure system, we don't depend on the chip alone. The
operator needs a "pin" or a "token" of some sort. the picture plus the
pin gets sent into the chip, and a digital signature comes out.

The point of s digitally signed picture is to suport someone's
testimony in (a) tying the raw picture to a specific camera, (b) an
operator via the pin/token and (c) that the raw picture has not been
tampered with so as to support any specific print made for evidence.

--
a d y k e s @ p a n i x . c o m

Don't blame me. I voted for Gore.

In article .com,
Vin McLellan wrote:
Anyone consider Schneier and Kelsey's work on secured logs as
potentially relevant to this problem? See:
http://www.schneier.com/paper-secure-logs.html

(A keyed MAC is used to cover each encrypted log entry along with a
"running hash," and that hash is updated by hashing the current
encrypted data into the old hash value. This could prove that a
sequence of photos was not tampered with. If that was integrated with a
strong authentication from the officer using the camera, wouldn't that
provide evidence as strong as the sworn testimony of the cop. Could
this be a partial solution?)

Several references to RSA's SecurID token, earlier in this discussion,
caught my attention. It's a bit OT for any thread but this one, but it
is also an interesting case-study of the attack/defense rhythm in
InfoSec, which might usefully inform this discussion. Far warning: if a
discussion of the SecurID's integrity bores you, skip this.

Al Dykes , a fellow believer, wrote:

Making the chip tamperproof and self-destructing is standard practice. Lots of us
have carried SecureID cards... that generated a new pseudo-random number
every 60 seconds that is part of the login sequence to some computer system
that, in my case, was managing billions of bucks, at BigBank. [...]

Actually, the design goal for the SecurID was to make it
tamper-resistant and tamper-evident -- so that a SecurID token, if
opened, will likely show damage that the user, or any casual observer,
can see.


I agree completely with this statement, and I was sloppy in my use of
"tamper proof". I know better. Applying this to the discussion;

Your honor, I testify that is picture came from my camera, but I can't
produce the camera because the dog ate it (or the Bad Guys took it
apart and disolved the crypto chip epoxy to get at the private key).

--
a d y k e s @ p a n i x . c o m

Don't blame me. I voted for Gore.

On 29 Jan 2006 22:12:54 -0800, "Vin McLellan"
wrote:

Anyone consider Schneier and Kelsey's work on secured logs as
potentially relevant to this problem? See:
http://www.schneier.com/paper-secure-logs.html

(A keyed MAC is used to cover each encrypted log entry along with a
"running hash," and that hash is updated by hashing the current

[snip, snip, snip]

To the extent that extended footnote this is OT, I beg the pardon of
the List.

Suerte,
_Vin

Vin,

Thanks for your post. Who woudda thunk it that there are at least 4,
probably more, security-type guys who participate in this list. With
all due respect to everyone of us, I think we're done with this topic.

Let's close this out before we're banned for speaking more
gobbledy-gook-y than a marketing guy on "X", if that is possible.

This is MY final post on this topic.

Peace

Father Kodak