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


