> Well the people involve are not dumb,
> right? They know
the capabilities of malware
> as well as most anyone.

Quite so, and that was what I found surprising.

> and thereby emulate the success of the
> operating system-based code signing systems.


I'm probably misinterpreting either you or the proposed system.  The usual 
code-signing system allows you to sign code with any cert you want, and it's up 
to the installer to choose to trust the cert (or something up the chain).  The 
ieee Taggant system seemed to be implying that you needed to use certs from a 
specific issuer.  That is a point where well-intentioned systems are can be too 
rigid and get ignored.  What am I missing?

Mike N


----- Original Message -----
From: Marsh Ray <[email protected]>
To: Michael Nelson <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, December 21, 2011 3:04 PM
Subject: Re: [cryptography] How are expired code-signing certs revoked?

On 12/21/2011 04:24 PM, Michael Nelson wrote:
> 
> Somewhat related: The IEEE is asking for proposals to develop and
> operate a CA as a part of their Taggant System.  This involves
> signing to validate the usage of packers (compressing executables).
> Packers can make it hard for anti-virus programs to spot malware.
> 
> Does this strike you as impractical?

Yes.

> It seems obvious to me that it will be a wasted effort.

Well the people involve are not dumb, right? They know the capabilities of 
malware as well as most anyone.

Here's an overview of the proposed system:

http://standards.ieee.org/news/2011/icsg_software.html
> "Today malware uses code-obfuscation techniques to disguise the
> malicious actions they take on your machine. As it is a hard problem
> to overcome such protection technologies, computer-security tools
> have started to become suspicious if an application uses code
> protection. As a result, even legitimate content-protection
> technology—generally put in place to either control application usage
> or protect intellectual property (IP) from exposure or tampering—can
> lead to false-positive detections. This forces technology vendors,
> such as software publishers, to make a decision between security and
> software accessibility. Joining the IEEE Software Taggant System
> enables SafeNet to provide our customers a way to enjoy the benefits
> of the proven IP protection without the risk of triggering a negative
> response from common malware protection tools."

So my interpretation of what they're essentially saying is this:

There are mostly three categories of software that need to modify executable 
memory pages:

A. Operating system loaders. EXEs and DLLs are things AV companies already 
scan. These modules can be code-signed today (and we all know that signed code 
is safe code).

B. The "legitimate" code obfuscation systems currently for IP protection and 
DRM.

C. Malware, which today uses code polymorphism ("unpackers") to evade 
signature-based detection.

When today's host based antimalware systems see the code modifications 
happening, it doesn't have an easy way to distinguish category B from category 
C. So these researchers propose to move category B applications into category A 
(under the threat of "risk of triggering a negative response from common 
malware protection tools") and thereby emulate the success of the operating 
system-based code signing systems.

Here's a classic article on the topic. In this case, the OS executable loader 
itself is used as the unpacker:
http://uninformed.org/index.cgi?v=6&a=3&p=2

- Marsh

_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to