[cryptography] How are expired code-signing certs revoked?
nelson_mikel at yahoo.com
Wed Dec 21 21:19:50 EST 2011
> 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?
----- Original Message -----
From: Marsh Ray <marsh at extendedsubset.com>
To: Michael Nelson <nelson_mikel at yahoo.com>
Cc: "cryptography at randombit.net" <cryptography at randombit.net>
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?
> 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:
> "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:
More information about the cryptography