Why is signing drivers such a mess?

> Driver signing is the most complex and expensive addition to hit

drivers since I have been writing them for 20 years. I am unsure why it
has to be this way. Answers to any of these questions might help me
understand this situation:

I’ve been putting signatures on Windows code since about 1995. Of course I
was also involved with early Internet commerce security so became very aware
of the need for signatures long ago. If I think about a year of work, say
it’s 2000 hours, I’d bet I spend less than 40 hours/year fooling with
digital signature stuff, implying the overhead is perhaps 2% or less.

  1. Why are there different classes of certificates for driver
    developers? For instance, why can’t the VeriSign organization
    certificate be used for code signing or a GlobalSign code signing
    certificate be used for winqual?

Driver signing is ONLY useful for preventing malicious code if the ability
to get a signing key is tightly controlled. My guess is different groups at
Microsoft have different levels of trust for the various Certificate
Authorities. Just by comparison, if you’re an Apple iPhone developer, you
ONLY can get signature keys directly from Apple, so really Microsoft is
allowing flexibility in the origin or many kinds of signing keys. Perhaps it
would just be simpler if Microsoft was the ONLY source for any keys used to
sign Windows software.

  1. Why are we absolutely required to do business with VeriSign for
    logo? What would happen if they went out of business?

Microsoft would pick another CA, or else do it themselves. The signatures
used for WHQL submissions are short lived and it would be quick to shift to
some other root. The actual keys used to sign code need to live much longer,
as the root keys are in systems out in the world.

  1. Why are certificates forced to expire every 1-3 years. Why can’t we
    just buy one that lasts forever?

That’s a policy choice of the CA’s. I assume a business model with long
expiration key’s is not as viable a business, and you DO want the CA’s to
stick around. There also is the security issue that shorter expirations are
safer. For example, employees at a company using a signature key might take
copies of the key when they leave, and if the expirations were say 10 years
the only way to deactivate the “stolen” keys would be to use certificate
revocation lists. The problem with CRL’s is if they grow to be very big,
they start to degrade signature checking performance. Having a 1 year
expiration on a signing key limits the lifetime that a stolen key can be
used. Is it really the expiration length or is it the price of the key. If
keys were really cheap, but expired in 3 months, that might actually be a
better security model, but may not be as good a business model for CA’s.

  1. Why are certificates so expensive? And why is it an annual fee based
    rather than a single setup fee? How much work does VeriSign do year 2
    compared to year 1?

Verisign I believe is a public company, and you could read their financials,
and report back here. If I’m not mistaken, CA’s are not exactly growing
money on trees, and some CA’s have even gone out of business. I do at times
wonder how it could cost $400 for a few kilobytes of data that are generated
in a few seconds. On the other hand they do need to have trustworthy people
and systems to verify the authenticity of somebody requesting a signature
key is authentic. My guess is you need to pay those people decent pages, and
perhaps run background checks against them, and a variety of other things to
trust them. The systems at Verisign seems like they need to assure
authentication of only trustworthy key requests, even though the people at
Verisign might be less trustworthy. What do you think is costs to create a
system that makes untrusted people work as a system of greater trust? The
problem is a LOT more complex than just running the key generation
algorithms on a processor.

  1. Why is so much red tape necessary to get a certificate issued? It is
    impractical to get a certificate for some mobile, internet based
    consultants who need to meet physical presence tests for somewhere they
    have barely stayed or won’t be there much longer anyway.

Like I said, digital signatures are ONLY useful if it’s hard for the bad
guys to get one. I personally have a driver consulting corporation, and we
have a GlobalSign key and the VeriSign whql submission key. We don’t view
$400/year for signing keys that big an expense. The $2000+/year we pay to
Microsoft for an MSDN subscription is a way bigger expense, but pretty much
a requirement.

  1. Why is signing the driver not part of the build tool? I modified
    mine by hand that everytime I press build it pops out a perfectly
    release signed driver, even for checked builds. I and my customers
    agree this has every advantage and no disdavantage.

Different companies may want different policies about who the private keys
are controller by. If the build process uses it then the private keys are
likely usable on any build machine with no direct user approval of the
signature. Unless the private key is stored in a hardware token, it also
means a security breach of a build machine might allow the theft of a
company’s signing keys. The only remedy to this would be to revoke the key,
which should make all software signed with that key stop working, basically
breaking EVERY customer out in the world.

At many companies I’ve been at, signing keys were pretty loosely controlled,
probably out of ignorance about the danger of them escaping into the wild. I
personally think a company should VERY closely control their private key, my
company does. Originally, the best security was to generate the key on a
hardware token, and connect that token to the machine used for signing. This
has the advantage that it’s impossible to steal the private key, as it’s
forever locked INSIDE the token hardware. Practically speaking, this is a
little inconvenient. An alternative is to generate the private/public key
pair, and get the public key signed by the CA. You then put this private
key/public certificate on removable media, like a CD or USB fob. On machines
that need to do signing, you then import the key pair as non-exportable.
Ideally, you import the key paid to a hardware token (or TPM) such that the
machine can do signing, but the key can’t be stolen. If you are very into
security, you should generate the key pair on a hardware token, and
PHYSICALLY secure that hardware token in way that’s only accessible for
FINAL signing of a driver by people in a company you trust. Putting the
hardware token in a safe, with combination known only to trusted people on
one way. One strategy to balance security and risk is you buy TWO signing
keys for each PRODUCT you make (yes, about $800/product) and you generate
one key pair with a name that distinguishes is as for test use only (Xyz
Inc. FOR INTERNAL TESTING ONLY). When you ship the final product, you take
the hardware token out of the safe (by a trusted person) and you sign the
final product bits with the real key pair. The advantage of two key pairs is
if the development/test key pair is compromised, you can just revoke it
(also when you ship). Revoking the REAL key pair used for your release
products brings down customers, which is bad.

I’d actually like to see key pair costs go way down, and security of them
improve. Like the Apple model of a EACH developer requires a key pair, with
a fairly short expiration. You still might do final product signing with a
very carefully controlled key pair.

  1. Why aren’t individuals allowed to write drivers anymore? They are
    prohibited from obtaining a certificate and thus barred from access to
    new Windows systems.

I’m basically an individual. I go through the trouble of having a
corporation, with a small number of employees, typically me and sometimes
one or two others. I deeply care about the security of products I work on
and the Windows platform in general. Actually, Dun and Bradstreet says my
company has been in business for 30 years now, although it has only been
incorporated in its current legal form since 1998. I fully expect that if
code signed by my company is malicious, men in police uniforms will show up
at my door and take me away. I also want any code YOU write, that’s
malicious, and distributed in any form to also be traceable to YOUR door, so
men in uniforms can show up and take you away. If you’re not willing to be
RESPONSIBLE for your code, I don’t want it running on any of MY or my
customers systems. If you not willing to assure that traceability of your
responsibility, I’m sorry to say you should not be allowed to distribute
Windows software to the public.

It’s not true that responsible software professionals who take the correct
legal steps, can’t write and distribute drivers for Windows anymore. It is
true that random people, who write software as a hobby, and who are not
willing to be legally responsible for the code they release into the world,
are deterred from releasing such code. For internal research, or personal
use, or even prototypes to a small number of people, you can just generate a
self-signed test certificate and enable test certificate mode on a specific
machine. Anybody with the WDK can generate the self-signed certificates and
there are no legal requirements of any kind. Random hackers (using the term
as a positive) can full write 64-bit Windows code and play with it. The
limits start happening when you want to distribute code to the public. There
are no real limits on writing code in you lab.

Microsoft’s requirements are much less stringent than Apple’s for iPhone
development. Since I’m a responsible software professional, I fully support
Microsoft’s efforts to assure the traceability of malicious software and the
stability of their OS. I’d actually support Microsoft going MUCH father, and
not allow execution of ANY code that wasn’t signed with trusted credentials.
This is basically the signature whitelist strategy of anti-virus protection,
instead of the current blacklist strategy.

People writing Java apps expected to be accessed online have needed to sign
everything for years. People writing user mode downloaded extensions like
ActiveX controls are been required to sign things for years.

I actually support PROCESSOR manufactures adding support for only running
code that is trusted by them. Things like firmware/BIOS.

Sure, I wish we lived in a world where EVERYBODY could be trusted, and no
signatures on code were ever required, but the reality of the world is you
can’t trust every piece of code. So can YOU tell me why YOU don’t feel like
the rules for preventing malicious code should apply to YOU? There are LOTS
of basically individuals, here on NTDEV, who do write 64-bit driver code,
and who do take the proper steps to assure responsibility is traceable.

  1. Since this forum is riddled with posts about driver signing is it
    time to open a new forum for it?

MOST of us don’t really have a problem with signing. I’m sure people who are
not willing to be responsible for their code do. Yes there are technical
nuances than need to be learned, but it’s generally a lot simpler than
writing drivers in general. I’m expecting to create a blog for my consulting
company in the near future, and we might have some info about digital
signatures eventually. Just doing a search on Microsoft docs and/or the
NTDEV archives will find all the details you need to do it.

Jan

> So can YOU tell me why YOU don’t feel like the rules for preventing malicious code

should apply to YOU?

This is not what the OP asks us about. What he asks us is “Why does MSFT offer so cumbersome approach to the problem of avoiding execution of untrusted KM code??? Is not there any better way to achieve the same objective???”

His post is perfectly reasonable, especially taking into account that one can certainly design more convenient (and efficient) means of avoiding execution of untrusted KM code, compared to driver signing. For example, drivers can be distributed not as executable PE images in “ready-to-run” form but as sets of binary sections derived from .pre-compiled OBJ files with a linker script describing them, so that linking a driver into a final executable image can take place on the target machine as a part of driver installation process. In order to ensure that package does not get altered by some third party on its way to the target machine it can get signed with a randomly generated by building environment private key and decrypted by the installer with its corresponding public key embedded into the package ( i.e. “either decrypt with this particular key or you are guaranteed to get a heap of binary rubbish out of this package”)

These final images can be signed with a unique key specific to a given installation (i.e. the one derived from a product key that is stored in the registry and is supposed to be unique) by a linker, indicating that the final executable image got linked precisely on the target machine. Therefore, kernel is not going to have any problem with telling drivers linked on the target system (which means they were actually installed by Admin user - it is needless to say that installation process should require Admin password) from the ones linked elsewhere (which means they may have turned up on the machine without user’s knowledge). The ones of the latter type should not ever be loaded, for understandable reasons…

As you can see, kernel may be made to load only those drivers that got installed upon Admin user’s decision without any problem mentioned by the OP anywhere in sight…

Anton Bassov

> 1. Why are there different classes of certificates for driver developers?

Microsoft decision. This unlinks Logo submission data from code signing
(which can also be done for user mode apps and macros, not only for
drivers).

  1. Why are we absolutely required to do business with VeriSign for logo?

Microsoft decision.

What would happen if they went out of business?

Very likely Microsoft would issue certificates for submission, or accept
certificates from another CA.

  1. Why are certificates forced to expire every 1-3 years. Why can’t we just buy one that lasts forever?

Microsoft decision. An expiring key like an expiring password is easier
to control.

  1. Why are certificates so expensive? And why is it an annual fee based rather than a single setup fee?

CA decision. They need a secure infrastructure, which is costly.

  1. Why is so much red tape necessary to get a certificate issued?

Because otherwise it is worthless - if the necessary trust/ID checks are
not done, you may as well not bother using certificates.

  1. Why is signing the driver not part of the build tool?

Microsoft decision.

Very likely because it is unsafe to allow anybody autmatically getting
signed anything. And this is what would happen if someone stole your
build PC. Or a backup of your hard disk.

Signing manually or on a specific, exrta protected, machine (which is
possible, and not difficult to setup), allows much better control.

  1. Why aren’t individuals allowed to write drivers anymore?

Microsoft decision. Not quite true. An individual can set up a company
with much less hassel than it costs to learn how to write drivers.

They are […] barred from access to new Windows systems.

Not true. Only 64bit systems are locked.

  1. Since this forum is riddled with posts about driver signing is it time to open a new forum for it?

Go ahead and open some somewhere if you feel the need for it. For me,
the forum search function has proved useful. But then, we got the
signing process up and running in 2006.

Some other comments: Be happy that you can get a certificate, and don’t
have to do signing using e.g. a smart card or another security token, or
online-only signing via an MS server.
MS has full control - it’s their OS. You are only allowed in as a guest.

xxxxx@gmail.com wrote:

  1. Since this forum is riddled with posts about driver signing is it time to open a new forum for it?

Since the answer is always the same, it hardly needs its own forum. The
answer is to follow this simple procedure:

  1. Read the driver-signing white paper
  2. Read the driver-signing white paper
  3. Try to understand the driver-signing white paper
  4. Do exactly what it says in the driver signing white paper
  5. Read the driver-signing white paper
  6. Do EXACTLY what it says in the driver signing white paper

For a second there I thought you were being serious.

> For a second there I thought you were being serious.

As I said earlier on this thread, all your questions are perfectly reasonable…

The problem is that you just asked all your questions in the wrong place. This is why you got such treatment. Never mind - after all, when you go to some religious sect’s website and start questioning the teachings of their gurus/leaders, what kind of replies would you expect to get from the followers, no matter how ridiculous these teachings are from “non-follower’s” perspective??? Therefore, you’ve got nothing to worry about…

Anton Bassov

wrote in message news:xxxxx@ntdev…

[snip]
> For example, drivers can be distributed not as executable PE images in
> “ready-to-run” form but as sets of binary sections derived from
> .pre-compiled OBJ files with a linker script describing them, so that
> linking a driver into a final executable image can take place on the
> target machine as a part of driver installation process.

Do you describe the IL and ngen? then wait a little for .NET based kernel…

> In order to ensure that package does not get altered by some third party
> on its way to the target machine it can get signed with a randomly
> generated by building environment private key and decrypted by the
> installer with its corresponding public key embedded into the package (
> i.e. “either decrypt with this particular key or you are guaranteed to get
> a heap of binary rubbish out of this package”)
>

“Sealing” the code is not hard, the hard problem is the proof of origin

> These final images can be signed with a unique key specific to a given
> installation (i.e. the one derived from a product key that is stored in
> the registry and is supposed to be unique) by a linker, indicating that
> the final executable image got linked precisely on the target machine.

Sure, and exactly in this way “serious” users can sign 3rd party drivers
with their own cert which they trust, and remove
all these new CAs installed by Windows Update.
If you are individual developer working for such “serious” customer, they
can just take your driver as is, and do the chores themselves.

>
> As you can see, kernel may be made to load only those drivers that got
> installed upon Admin user’s decision without any problem mentioned by the
> OP anywhere in sight…

Amen.
–pa

>
>
> Anton Bassov
>

> Do you describe the IL and ngen? then wait a little for .NET based kernel…

Actually, I got the main idea of what I had described from the Linux kernel that fails insmod() in case of symbol mismatch. In practice it means that if you want to distribute a module that somehow relies upon GPLed kernel exports (i.e. something that the vast majority of modules do, although there are some rare exceptions like NVIDIA drivers) and make it work everywhere you have to provide it as a bunch of source files with Makefile so that it can get built against currently running kernel version during installation process.

I just adjusted this idea to Windows specifics. Once Windows is not an open-source system the requirement of providing drivers as .c source files does not apply, for understandable reasons. However, the idea in itself seems to be valid even under Windows - it just requires some modifications…

“Sealing” the code is not hard, the hard problem is the proof of origin

Actually, I am not sure that the concept of " proof of origin" is of so vital importance to drivers, in the first place - it seems to be applicable more to web applications that rely upon ActiveX components, Java applets and other UM plugins that you are prompted to install on every other webpage if you want to take the full advantage of its contents… However, KM driver is a relatively “rare beast” that comes either as a part of a very specific product that requires a full-fledged setup, or as a piece of a malware that gets installed without user’s knowledge .

Therefore, I think the main security-related questions with drivers are more of “Does the user know about its very existence” and “Has it been modified/replaced after installation”, rather than “Who wrote it”…

Anton Bassov

The US has an excess of lawyers. The proof of origin allows the vultures
someone to sue.

wrote in message news:xxxxx@ntdev…
>> Do you describe the IL and ngen? then wait a little for .NET based
>> kernel…
>
> Actually, I got the main idea of what I had described from the Linux
> kernel that fails insmod() in case of symbol mismatch. In practice it
> means that if you want to distribute a module that somehow relies upon
> GPLed kernel exports (i.e. something that the vast majority of modules do,
> although there are some rare exceptions like NVIDIA drivers) and make it
> work everywhere you have to provide it as a bunch of source files with
> Makefile so that it can get built against currently running kernel version
> during installation process.
>
> I just adjusted this idea to Windows specifics. Once Windows is not an
> open-source system the requirement of providing drivers as .c source files
> does not apply, for understandable reasons. However, the idea in itself
> seems to be valid even under Windows - it just requires some
> modifications…
>
>> “Sealing” the code is not hard, the hard problem is the proof of origin
>
> Actually, I am not sure that the concept of " proof of origin" is of so
> vital importance to drivers, in the first place - it seems to be
> applicable more to web applications that rely upon ActiveX components,
> Java applets and other UM plugins that you are prompted to install on
> every other webpage if you want to take the full advantage of its
> contents… However, KM driver is a relatively “rare beast” that comes
> either as a part of a very specific product that requires a full-fledged
> setup, or as a piece of a malware that gets installed without user’s
> knowledge .
>
> Therefore, I think the main security-related questions with drivers are
> more of “Does the user know about its very existence” and “Has it been
> modified/replaced after installation”, rather than “Who wrote it”…
>
>
> Anton Bassov
>
>
>

I think it was very nice for Jan Bottorff to take all the time that such a complete answer obviously took to write. His answer is clear, complete, and correct.

Now, we can debate whether “hobby” developers should be excluded from being able to supply drivers to their communities of interest (as the currently are with the driver signing program). I think it’s a shame that they are, personally.

I’d LOVE to see a “we’ll sign your drivers for a few bucks” type company emerge. I’ve even heard rumblings of one such company being organized (nothing to do with OSR, by the way). I think such a company would provide a valuable service to numerous hobby-oriented communities.

Peter
OSR

> I’d LOVE to see a “we’ll sign your drivers for a few bucks” type company emerge.

How a company like is supposed to get its key to sign code??? Will VeriSign or any other signing authority issue a key for a company that makes money by signing code to anyone who wishes to pay few dollars , without assuming any legal liability for damages that code signed with its key may do??? After all, it just defeats the very purpose of code signing, in the first place…

However, if what you had mentioned in your post, indeed, becomes true, if will be just a wonderful practical explanation of why the very concept of driver signing (at least in its currently existing form) is fundamentally flawed in itself…

Anton Bassov

>

> I’d LOVE to see a “we’ll sign your drivers for a few bucks” type
company
> emerge.

How a company like is supposed to get its key to sign code??? Will
VeriSign
or any other signing authority issue a key for a company that makes
money by
signing code to anyone who wishes to pay few dollars , without
assuming any
legal liability for damages that code signed with its key may do???
After
all, it just defeats the very purpose of code signing, in the first
place…

However, if what you had mentioned in your post, indeed, becomes true,
if will
be just a wonderful practical explanation of why the very concept of
driver
signing (at least in its currently existing form) is fundamentally
flawed in
itself…

I think that the practice itself would be okay, as long as everyone
understands that if even 1 single malicious binary is ever signed
with that key, that key could be revoked, with obvious consequences to
everything else signed with that key.

It will be interesting to see what happens when 64 bit operating systems
starts to outnumber 32 bit operating systems on PC’s and become a
worthwhile target for rootkit style malware… I’ve said before that I
think the bad guys will just find a backdoor that doesn’t require
signing if they want to badly enough, but it remains to be seen if this
is the case or not…

James

> as long as everyone understands that if even 1 single malicious binary is ever signed with

that key, that key could be revoked, with obvious consequences to everything else signed with that key.

As long as someone understands the above, he will immediately understand its implications and imagines the ensuing mess that he is more than likely to deal with, regardless of his role in the scheme- no matter if you happen to be a code writer, a signing authority or an “intermediate” company that signs someone else’s code with its key, the whole thing is just bound to cause you a lot of pain in the neck, in the back
and below . …

Anton Bassov

>

> as long as everyone understands that if even 1 single malicious
binary is
> ever signed with
> that key, that key could be revoked, with obvious consequences to
everything
> else signed with that key.

As long as someone understands the above, he will immediately
understand its
implications and imagines the ensuing mess that he is more than
likely to
deal with, regardless of his role in the scheme- no matter if you
happen to be
a code writer, a signing authority or an “intermediate” company that
signs
someone else’s code with its key, the whole thing is just bound to
cause you a
lot of pain in the neck, in the back
and below . …

… which was my point :slight_smile: Easier just to purchase a proper key.

James

a proper key? the infrastructure is not cryptographically sound. ask
any one at microsoft, they’ll go umm ahhh.

just my personal crypto experience.

brucee

On 1/4/10, James Harper wrote:
> >
> > > as long as everyone understands that if even 1 single malicious
> binary is
> > > ever signed with
> > > that key, that key could be revoked, with obvious consequences to
> everything
> > > else signed with that key.
> >
> > As long as someone understands the above, he will immediately
> understand its
> > implications and imagines the ensuing mess that he is more than
> likely to
> > deal with, regardless of his role in the scheme- no matter if you
> happen to be
> > a code writer, a signing authority or an “intermediate” company that
> signs
> > someone else’s code with its key, the whole thing is just bound to
> cause you a
> > lot of pain in the neck, in the back
> > and below . …
> >
>
> … which was my point :slight_smile: Easier just to purchase a proper key.
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Verisign doesn’t care WHY, but WHO you are. You must be a business via one
of several ways to acquire that, and of course you must be willing to part
with 800 schekels for the class 3 code signing certificate. I’ve paid for
that certificate twice, and the ONLY contact I have with Veri-sign from the
time the certificate is delivered, was for them to tell me they wanted more
schekels when the certificate was about to expire. Not once did Verisign
EVER asked why or for what I intended to use the ceretificate.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Sunday, January 03, 2010 11:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Why is signing drivers such a mess?

I’d LOVE to see a “we’ll sign your drivers for a few bucks” type company
emerge.

How a company like is supposed to get its key to sign code??? Will
VeriSign or any other signing authority issue a key for a company that makes
money by signing code to anyone who wishes to pay few dollars , without
assuming any legal liability for damages that code signed with its key may
do??? After all, it just defeats the very purpose of code signing, in the
first place…

However, if what you had mentioned in your post, indeed, becomes true, if
will be just a wonderful practical explanation of why the very concept of
driver signing (at least in its currently existing form) is fundamentally
flawed in itself…

Anton Bassov


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus signature
database 4743 (20100104) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 4743 (20100104) __________

The message was checked by ESET Smart Security.

http://www.eset.com

xxxxx@gmail.com wrote:

Driver signing is the most complex and expensive addition to hit drivers since I have been writing them for 20 years. I am unsure why it has to be this way.

In retrospect, I don’t think this situation is any more complicated than
any of the other learning curves we climb to get a driver out into the
public. There is a large amount of boilerplate in the recipe, but once
you get the recipe right, it just works from then on.

Answers to any of these questions might help me understand this situation:

  1. Why are there different classes of certificates for driver developers? For instance, why can’t the VeriSign organization certificate be used for code signing or a GlobalSign code signing certificate be used for winqual?

Partly, this is so certificate vendors can generate profit. The
certificate specification (and there IS a spec) does define a large
number of different “certificate uses”. The usage codes are embedded in
the certificate. This goes with the “perceived value” principle; some
usages are perceived as being more valuable than other usages, so the
capitalist principle is that you should pay more.

There IS some overlap. You can get a single VeriSign certificate that
does code signing AND works for Winqual. Neither VeriSign nor Winqual
are particularly interested in reducing your cost of business.

  1. Why are we absolutely required to do business with VeriSign for logo? What would happen if they went out of business?

This is probably historical. Winqual has had the certificate
requirement for a very very long time, and when they started, there
really were no other alternatives. No one of importance has ever
complained seriously about it, so there has been no incentive to
change. After all, the $99 certificate is a relatively minor cost,
compared to the cost of submitting driver packages. The onesy-twosy
shops are not the important people. The important people are the Dells
and HPs of the world, who submit dozens or hundreds of driver packages
throughout the year.

  1. Why are certificates forced to expire every 1-3 years. Why can’t we just buy one that lasts forever?

Because people (and companies) move. The fundamental purpose for driver
signing is to provide a reliable path for lawyers to find you when your
driver causes damage. VeriSign is not going to promise that you can
still be reached at the address you signed up with 8 years ago.

  1. Why are certificates so expensive? And why is it an annual fee based rather than a single setup fee? How much work does VeriSign do year 2 compared to year 1?

Capitalism. You and I both know that the incremental cost of a
certificate is nearly nil. They do 10 minutes of automated background
checking by looking at your Dun & Bradstreet database record, and that’s
pretty much it.

  1. Why is so much red tape necessary to get a certificate issued? It is impractical to get a certificate for some mobile, internet based consultants who need to meet physical presence tests for somewhere they have barely stayed or won’t be there much longer anyway.

And those are exactly the people who should not be getting certificates,
because they can’t be reached when liability issues arise.

As disgusting and disappointing as it may be, the Windows world of today
is not like the Wild West MS-DOS world of 1987, where virtually all of
the good stuff came from one-off shareware authors doing it for the
fun. Today, what we have is much more like the mainframe world of
1975. PCs are now corporate mission-critical. Rogue kernel code can
cause millions of dollars of damage to a company. If you want to submit
your driver into that world, you need to be willing to submit to a fair
amount of scrutiny. That’s just the way it is.

  1. Why is signing the driver not part of the build tool? I modified mine by hand that everytime I press build it pops out a perfectly release signed driver, even for checked builds. I and my customers agree this has every advantage and no disdavantage.

I’m not sure what you mean. You can certainly add a “signtool” call to
your sources/makefile setup so that it runs when you call “build”.
There don’t happen to be any samples that show this, but that doesn’t
mean it’s “not part of the build tool”.

  1. Why aren’t individuals allowed to write drivers anymore? They are prohibited from obtaining a certificate and thus barred from access to new Windows systems.

Liability. Individuals are inherently less reachable than corporations
when subpeona time rolls around.

  1. Since this forum is riddled with posts about driver signing is it time to open a new forum for it?

I don’t think so. Like most driver questions, once you climb over the
learning curve hump, this becomes a non-issue.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

James Harper wrote:

It will be interesting to see what happens when 64 bit operating systems
starts to outnumber 32 bit operating systems on PC’s

This seems to be happening.

The last few days I was looking for netbooks. To my surprise some
companies pre-install 64bit versions of Windows on some of them.

NOT for a hobby developer, who would the main target of such an enterprise… and for whom the idea of “if one piece of software is determined to be malware the signature winds up on the CRL” isn’t such a big deal.

His customers, each having paid zero to a few dollars for the software, come back to him and say “your stuff doesn’t work” – to which he answers “oh, darn! You’re right. Sorry. Disable driver signature enforcement and reboot” or whatever, until he gets his NEXT signature from SigsRus.com

Peter
OSR

At least for the hobbyist, are there alternatives to the $400/year VeriSign
ID? I’d pay $50/year (the cost of some alternative certificate authorities)
but for the 0.1 drivers per year I write these days, I cannot justify the
high costs of the VeriSign certificate.

There was some talk at earlier driver conferences about alternate
certificate authorities being approved, but I have not heard anything about
whether this went through.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, January 04, 2010 2:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Why is signing drivers such a mess?

NOT for a hobby developer, who would the main target of such an
enterprise… and for whom the idea of “if one piece of software is
determined to be malware the signature winds up on the CRL” isn’t such a big
deal.

His customers, each having paid zero to a few dollars for the software, come
back to him and say “your stuff doesn’t work” – to which he answers “oh,
darn! You’re right. Sorry. Disable driver signature enforcement and
reboot” or whatever, until he gets his NEXT signature from SigsRus.com

Peter
OSR


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.