120 lines
5.3 KiB
Plaintext
120 lines
5.3 KiB
Plaintext
From secprog-return-508-jm=jmason.org@securityfocus.com Fri Sep 20 11:28:44 2002
|
|
Return-Path: <secprog-return-508-yyyy=example.com@securityfocus.com>
|
|
Delivered-To: yyyy@localhost.example.com
|
|
Received: from localhost (jalapeno [127.0.0.1])
|
|
by jmason.org (Postfix) with ESMTP id 2E32016F03
|
|
for <jm@localhost>; Fri, 20 Sep 2002 11:28:42 +0100 (IST)
|
|
Received: from jalapeno [127.0.0.1]
|
|
by localhost with IMAP (fetchmail-5.9.0)
|
|
for jm@localhost (single-drop); Fri, 20 Sep 2002 11:28:42 +0100 (IST)
|
|
Received: from outgoing.securityfocus.com (outgoing2.securityfocus.com
|
|
[205.206.231.26]) by dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id
|
|
g8JNJ5C07887 for <jm@jmason.org>; Fri, 20 Sep 2002 00:19:06 +0100
|
|
Received: from lists.securityfocus.com (lists.securityfocus.com
|
|
[205.206.231.19]) by outgoing.securityfocus.com (Postfix) with QMQP id
|
|
43B578F293; Thu, 19 Sep 2002 16:23:04 -0600 (MDT)
|
|
Mailing-List: contact secprog-help@securityfocus.com; run by ezmlm
|
|
Precedence: bulk
|
|
List-Id: <secprog.list-id.securityfocus.com>
|
|
List-Post: <mailto:secprog@securityfocus.com>
|
|
List-Help: <mailto:secprog-help@securityfocus.com>
|
|
List-Unsubscribe: <mailto:secprog-unsubscribe@securityfocus.com>
|
|
List-Subscribe: <mailto:secprog-subscribe@securityfocus.com>
|
|
Delivered-To: mailing list secprog@securityfocus.com
|
|
Delivered-To: moderator for secprog@securityfocus.com
|
|
Received: (qmail 2162 invoked from network); 19 Sep 2002 21:10:14 -0000
|
|
From: "Michael McKay" <mmckay@iscubed.com>
|
|
To: "'Bryan Feir'" <bryan@sgl.crestech.ca>,
|
|
<secprog@securityfocus.com>, <strange@nsk.yi.org>
|
|
Subject: RE: Secure Sofware Key
|
|
Date: Thu, 19 Sep 2002 14:44:22 -0700
|
|
Message-Id: <004401c26025$c4aa3260$01000001@iS3Inc>
|
|
MIME-Version: 1.0
|
|
Content-Type: text/plain; charset="US-ASCII"
|
|
Content-Transfer-Encoding: 7bit
|
|
X-Priority: 3 (Normal)
|
|
X-Msmail-Priority: Normal
|
|
X-Mailer: Microsoft Outlook, Build 10.0.4024
|
|
Importance: Normal
|
|
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
|
|
In-Reply-To: <20020904151603.B1300@sgl.crestech.ca>
|
|
X-Spam-Status: No, hits=-3.6 required=5.0
|
|
tests=EMAIL_ATTRIBUTION,IN_REP_TO,KNOWN_MAILING_LIST,
|
|
QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES
|
|
version=2.50-cvs
|
|
X-Spam-Level:
|
|
|
|
Bryan Feir [mailto:bryan@sgl.crestech.ca] wrote:
|
|
|
|
>Of course, once one player key was broken, dealing with the rest became
|
|
> a known plaintext attack, and the rest of the player keys went down
|
|
like
|
|
> a row of dominos.
|
|
|
|
The actual follow-up to the Xing player break was more interesting than
|
|
that. The mere knowledge of known plaintext (a corresponding input and
|
|
output) does not necessarily make it trivial to break a properly
|
|
designed systems and/or algorithm. The primary reason it was easy for
|
|
CSS is because the CSS key was only 40-bits, and thereby easy to break
|
|
with exhaustive search attacks. It was only 40-bits (speculated)
|
|
because of a misunderstanding of the government cryptography export
|
|
rules at the time.
|
|
|
|
Even more interesting, to me at least, was that soon after the Xing
|
|
player break, people started studying the CSS algorithm itself. They
|
|
rapidly found serious design flaws which left the 40-bit CSS algorithm
|
|
with an actual strength of around 23-bits (from memory, and new attacks
|
|
might have further reduced the strength). This is another great example
|
|
showing why proprietary cryptography algorithms should be viewed with
|
|
the greatest of suspicion.
|
|
|
|
|
|
On Tue, Sep 03, 2002 at 09:03:40PM -0400, Yannick Gingras wrote:
|
|
> This make me wonder about the relative protection of smart cards.
|
|
They have
|
|
> an internal procession unit around 4MHz. Can we consider them as
|
|
trusted
|
|
> hardware ?
|
|
|
|
Yes and no. You can put a limited amount of trust in a smart card.
|
|
There have been any number of very clever attacks against smartcards
|
|
(Ross Anderson in the UK has documented quite a few of these), and
|
|
smartcard manufactures are usually one step behind these attacks. A
|
|
well designed system assumes that a system smartcard will be completely
|
|
compromised at some point, giving an adversary all of the secrets
|
|
contained in the smartcard. The cryptography industry has developed a
|
|
variety of techniques that can reduce the impact of a compromise,
|
|
including unique keys per smartcard and forward security techniques.
|
|
|
|
|
|
Luciano Rocha [strange@nsk.yi.org] wrote:
|
|
|
|
> The problem is that that piece of hardware is trustworthy, but the
|
|
rest of
|
|
> the PC isn't, so a cracker just needs to simulate the lock/smart card,
|
|
or
|
|
> peek at the executable after the lock has been deactivated.
|
|
|
|
Going back to the original question, once the encrypted material goes
|
|
outside the trusted hardware, it is impossible to "unbreakably" protect
|
|
it. There may be some mitigation steps you can take, such as the SDMI
|
|
watermarking, but most schemes to date have been easily broken.
|
|
|
|
Another consideration is the value of what you are trying to protect.
|
|
While there is no such thing as unbreakable, adding more cost (both in
|
|
terms of price and hassle-factor) can greatly improve the protection.
|
|
Since you are talking about the use of standard PC workstations, I
|
|
presume what you are trying to protect is not THAT valuable. I'm afraid
|
|
most security measures don't come for free.
|
|
|
|
|
|
Michael McKay
|
|
Director of Software Development
|
|
mmckay@iscubed.com
|
|
|
|
Information Security Systems & Services Inc.
|
|
19925 Stevens Creek Blvd. Cupertino, CA 95014
|
|
Phone: 408.725.7136 x 4138 Fax: 408.973.7239 www.iscubed.com
|
|
|
|
|