Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Why is signing drivers such a mess?

Bob_KroeterBob_Kroeter Member Posts: 65
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:

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?

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

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

4. 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?

5. 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.

6. 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.

7. 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.

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

Comments

  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 4. 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?
    >
    > 5. 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.
    >
    > 6. 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.
    >
    > 7. 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.
    >

    The answer to almost all of your questions, but especially to 4-7, is
    that you are supposed to keep your certificate in a highly secure place.
    You should use a passphrase that you have to enter every time you want
    to use it, and that passphrase shouldn't be stored somewhere like in a
    build script. The machine that does the signing shouldn't be connected
    to the network. The fact that you have integrated the signing process
    into your automated build script suggests you have violated all of the
    above :)

    James
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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.

    > 2. 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.

    > 3. 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.


    > 4. 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.

    > 5. 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.

    > 6. 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.

    > 7. 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.

    > 8. 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
  • anton_bassovanton_bassov Member Posts: 5,010
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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).

    > 2. 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.


    > 3. 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.


    > 4. 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.



    > 5. 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.


    > 6. 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.


    > 7. 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.


    > 8. 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.
  • J._J._FarrellJ._J._Farrell Member Posts: 200
    xxxxx@gmail.com wrote:
    >
    > 8. 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
  • Bob_KroeterBob_Kroeter Member Posts: 65
    For a second there I thought you were being serious.
  • anton_bassovanton_bassov Member Posts: 5,010
    > 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
  • Pavel_APavel_A Member Posts: 2,674
    <xxxxx@hotmail.com> 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
    >
  • anton_bassovanton_bassov Member Posts: 5,010
    > 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
  • David_J._CraigDavid_J._Craig Member Posts: 1,885
    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
    >
    >
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member Posts: 5,010
    > 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
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > > 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
  • anton_bassovanton_bassov Member Posts: 5,010
    > 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
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > > 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 :) Easier just to purchase a proper key.

    James
  • Bruce_EllisBruce_Ellis Member Posts: 25
    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 <xxxxx@bendigoit.com.au> 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 :) 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
    >
  • Gary_Little-3Gary_Little-3 Member Posts: 1,208
    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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,004
    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.

    > 2. 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.

    > 3. 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.

    > 4. 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.

    > 5. 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.

    > 6. 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".

    > 7. 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.

    > 8. 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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    <QUOTE>
    Easier just to purchase a proper key.
    </QUOTE>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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?


    Easier just to purchase a proper key.


    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.
  • anton_bassovanton_bassov Member Posts: 5,010
    > OT for a hobby developer, who would the main target of such an enterprise...

    I just wonder if the company that signs his code will be forced to assume liability for it ...

    Let's face it - the vast majority of malware in existence is produced exactly by developers of the type you have mentioned, and if someone who signs his code is not forced to assume liability for it, the very idea of code signing loses any practical meaning....

    > His customers, each having paid zero to a few dollars for the software,

    Well, I think the vast majority of his "customers" would not mind paying more than few dollars to ensure that his "production" never gets installed on their PCs....


    Anton Bassov
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    <QUOTE>
    is not forced to assume liability for it
    </QUOTE>

    "forced" by whom? Stalin's been dead a long time, dude...

    As far as *I* know, the only thing that could happen to the company signing the driver is that MSFT will revoke the cert. Oh well!

    <QUOTE>
    the vast majority of malware in existence is produced exactly by developers of the type you have mentioned
    </QUOTE>

    Whatever. But the vast majority of companies that would want this service don't produce malware. They produce drivers for tiny markets, in their spare time, for the sheer joy of assisting the community of which they are a part. Or something.

    The company doing the signing will probably WANT to do some minimal amount of due diligence, just to avoid having to keep getting new certs. But, whatever.

    Nobody HAS to install a driver signed by "WeSignUrShitForTenEuros.com" -- It's entirely up to the user. Like I said... whatever.

    It'd be a damn-sight better than hobby devs not be able to have people use their stuff AT ALL without disabling driver signing completely.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member Posts: 5,010
    > "forced" by whom?

    By the court, apparently.....

    Look -the very idea behind code signing is to make it possible to trace code originator in case if it turns out to be malicious. Therefore, if you sign a piece of software with your key and then it turns out that this particular piece of software, say, steals credit card numbers, it will be you who gets summoned to court, because it is signed with your key, and, hence, for the time being you are treated as its originator. What I meant in my previous post is whether you will be kept liable for everything that code signed with your key does, or whether you will be allowed just to shrug it off like "I don't know anything - I sign anything for anyone who pays me few dollars for it". In the latter case the whole idea of code signing does not seem to be particularly meaningful, don't you think....

    > Stalin's been dead a long time, dude...

    Where is Mr. Kyler - I bet he is going to love it......


    > Nobody HAS to install a driver signed by "WeSignUrShitForTenEuros.com"

    IIRC, malware never had a reputation of asking users whether they want to install it....


    Anton Bassov
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,004
    Joseph M. Newcomer wrote:
    > 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.
    >

    I just renewed my GlobalSign certificate, $400 for 3 years. It has
    worked fine for me for the past two years. There are about 8
    certificate authorities with valid cross-certificates available,
    although because of mergers and acquisitions, that's down to 3 different
    corporations.

    http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,265
    <QUOTE>
    What I meant in my previous post is whether
    you will be kept liable for everything that code signed with your key does, or
    whether you will be allowed just to shrug it off like "I don't know anything - I
    sign anything for anyone who pays me few dollars for it". In the latter case the
    whole idea of code signing does not seem to be particularly meaningful, don't
    you think....
    </QUOTE>

    No. I think there's room for a legitimate middle ground.

    Let's say you and I start a web-based company, "A&P, LLC", that signs drivers for people at... I don't know... US$50/driver.

    Here's how we do it: Company X sends us a request to sign their driver package. We:

    a) Execute an NDA with Company X, that includes a "hold harmless" clause saying A&P LLC won't be responsible for any crap we sign for Company X.

    b) Have Company X send us their driver, in source code form, with build instructions.

    c) We examine the driver (handwave, handwave), and if we don't see anything we hate, we build it per the instructions.

    d) We sign the .SYS file and the package.

    e) We return this package to Company X and they can distribute it to their users.

    Total time invested: 10 minutes.

    Service to the community: Priceless.

    I don't expect A&P LLC would be liable for the driver if it didn't work, failed to meet its specs, or if it did anything malicious. We didn't MAKE it. We just signed the package.

    So, somewhere between "We're fully responsible" and "We sign anything"...

    To me, that would work nicely.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Calvin_Guan-2Calvin_Guan-2 Member Posts: 311
    [quote]
    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.
    [/quote]

    Tim,

    How dare you miss IBM?:)

    Actually, most of time, OEMs get the signed drivers from IHVs (ATi, Broadcom, Emulex, Intel, Nvidia, Qlogic etc...) who provide chips or adapters (video, network, storage) for their platforms. IHVs will have to signed their drivers. We do sign a lot of drivers. Fortunately, I don't have to worry about it nor do I want to know what VeriSign, class 3 are. The only thing about verisign that I know is it would appear in my browser when I log into my bank or 401k accounts. All I have to do is providing a test CAT for our PQA just to be good enough to get rid of the "press F8 thingy".

    Calvin
  • Bruce_EllisBruce_Ellis Member Posts: 25
    Paying big bucks to someone who only cares about the money does not
    ensure quality or liability. Try this for a laugh - try and connect
    more than one model of HP printer to any PC. The drivers fight over
    "who is the real messiah" and you end up with a different mess every
    time you boot. Complain to HP and they say "don't do that". Complain
    to Verisign and it becomes blame-relay.

    This is real, in this room. I have a scanner, a laser printer, and a
    photo printer.

    Solution? Well use more computers...

    brucee

    On 1/5/10, xxxxx@yahoo.ca <xxxxx@yahoo.ca> wrote:
    > [quote]
    > 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.
    > [/quote]
    >
    > Tim,
    >
    > How dare you miss IBM?:)
    >
    > Actually, most of time, OEMs get the signed drivers from IHVs (ATi, Broadcom, Emulex, Intel, Nvidia, Qlogic etc...) who provide chips or adapters (video, network, storage) for their platforms. IHVs will have to signed their drivers. We do sign a lot of drivers. Fortunately, I don't have to worry about it nor do I want to know what VeriSign, class 3 are. The only thing about verisign that I know is it would appear in my browser when I log into my bank or 401k accounts. All I have to do is providing a test CAT for our PQA just to be good enough to get rid of the "press F8 thingy".
    >
    > Calvin
    >
    >
    > ---
    > 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
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,004
    Bruce Ellis wrote:
    > Paying big bucks to someone who only cares about the money does not
    > ensure quality or liability. Try this for a laugh - try and connect
    > more than one model of HP printer to any PC. The drivers fight over
    > "who is the real messiah" and you end up with a different mess every
    > time you boot.

    HP has become one of the worst. Their hardware is good, but their
    driver people should be hung at dawn. When I install a printer, ALL I
    WANT is a driver that turns GDI calls into dots on paper. I don't want
    600 megabytes of download, 39 DLLs, 22 full-time processes, 18 injected
    hooks, 15 desktop icons, 13 unrelated utilities, 9 RSS subscriptions, 7
    IE toolbars, a cheerful audio-driven help system and a partridge in a
    pear tree. I did not buy my computer for the sole purpose of talking to
    that printer.

    It drives me nuts. That's why I bought an Epson last time. They aren't
    nearly as bad.

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >I don't expect A&P LLC would be liable for the driver if it didn't
    work, failed to meet its specs, or if it did anything malicious. We
    didn't MAKE it. >We just signed the package.
    >So, somewhere between "We're fully responsible" and "We sign
    anything"...
    >To me, that would work nicely.

    So what happens to the customer ? what does he do in case his system
    crashes at home.? Who should he contact ? does the package installation
    or the signing framework have enough information to tell the customer
    that A&P LLC can only be trusted for delivery of package and not for
    it's quality ?

    Harish

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

    <QUOTE>
    What I meant in my previous post is whether
    you will be kept liable for everything that code signed with your key
    does, or
    whether you will be allowed just to shrug it off like "I don't know
    anything - I
    sign anything for anyone who pays me few dollars for it". In the latter
    case the
    whole idea of code signing does not seem to be particularly meaningful,
    don't
    you think....
    </QUOTE>

    No. I think there's room for a legitimate middle ground.

    Let's say you and I start a web-based company, "A&P, LLC", that signs
    drivers for people at... I don't know... US$50/driver.

    Here's how we do it: Company X sends us a request to sign their driver
    package. We:

    a) Execute an NDA with Company X, that includes a "hold harmless" clause
    saying A&P LLC won't be responsible for any crap we sign for Company X.

    b) Have Company X send us their driver, in source code form, with build
    instructions.

    c) We examine the driver (handwave, handwave), and if we don't see
    anything we hate, we build it per the instructions.

    d) We sign the .SYS file and the package.

    e) We return this package to Company X and they can distribute it to
    their users.

    Total time invested: 10 minutes.

    Service to the community: Priceless.

    I don't expect A&P LLC would be liable for the driver if it didn't work,
    failed to meet its specs, or if it did anything malicious. We didn't
    MAKE it. We just signed the package.

    So, somewhere between "We're fully responsible" and "We sign
    anything"...

    To me, that would work nicely.

    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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA