Getting MSP430 USB Driver Signed By Microsoft
$begingroup$
I am developing a product which utilizes an MSP430 microcontroller with a built-in USB module. I obtained a PID from Texas Instruments and used their tools to generate the descriptors, as well as a .inf file to install the driver software. The obvious issue is that due to the custom nature of these files, a popup is presented (on Windows 7) upon plugging in the USB cable that warns the user that the driver is not signed. I believe on Windows 8 and Windows 10 it simply blocks it and does not indicate this to the user at all.
As this is a full-featured product which my company is planning to release, we need to obtain a driver certificate (I believe in the form of a .cat file?) that we can provide to the customer so that they can install the device driver software without issue.
I have been through quite a bit of the Microsoft documentation (most notably this document) trying to get a grasp of what is required in order to get a driver signed, but unfortunately this is over my head at the moment.
This is what I think I understand so far:
- I need to submit my driver (.inf file?) to a Microsoft-authorized certificate authority (CA). There are a number of these out there, so I would need to find one that signs drivers.
- After selecting a CA, generally I will need to pay an annual fee (most commonly for 1, 2, or 3 years) for their service. Any drivers I generate during this time will be permanently signed, even after the service expires. If I want to change the driver or create a new one after the service has expired, I will need to buy service for another 1, 2, or 3 years.
- After paying the fee, the CA will generate a .cat file which is a certificate assuring that the driver I gave them will not be changed. If it does it will no longer match the .cat file and an error will appear during installation
Is this correct? At the risk of sounding like I'm seeking recommendations for specific CAs (I'm not, mind you), where can I find a list of CAs that are able to do this certification for me? Even better would be their websites and/or prices for different service durations. Has anyone here had direct experience getting a driver for a USB microcontroller-based product signed by a CA, who would be able to help me understand and get through the process? I have already posted to the MSDN forums but it seems pretty dead there - It's been two days and my thread only has a handful of views.
usb msp430 microsoft
$endgroup$
|
show 6 more comments
$begingroup$
I am developing a product which utilizes an MSP430 microcontroller with a built-in USB module. I obtained a PID from Texas Instruments and used their tools to generate the descriptors, as well as a .inf file to install the driver software. The obvious issue is that due to the custom nature of these files, a popup is presented (on Windows 7) upon plugging in the USB cable that warns the user that the driver is not signed. I believe on Windows 8 and Windows 10 it simply blocks it and does not indicate this to the user at all.
As this is a full-featured product which my company is planning to release, we need to obtain a driver certificate (I believe in the form of a .cat file?) that we can provide to the customer so that they can install the device driver software without issue.
I have been through quite a bit of the Microsoft documentation (most notably this document) trying to get a grasp of what is required in order to get a driver signed, but unfortunately this is over my head at the moment.
This is what I think I understand so far:
- I need to submit my driver (.inf file?) to a Microsoft-authorized certificate authority (CA). There are a number of these out there, so I would need to find one that signs drivers.
- After selecting a CA, generally I will need to pay an annual fee (most commonly for 1, 2, or 3 years) for their service. Any drivers I generate during this time will be permanently signed, even after the service expires. If I want to change the driver or create a new one after the service has expired, I will need to buy service for another 1, 2, or 3 years.
- After paying the fee, the CA will generate a .cat file which is a certificate assuring that the driver I gave them will not be changed. If it does it will no longer match the .cat file and an error will appear during installation
Is this correct? At the risk of sounding like I'm seeking recommendations for specific CAs (I'm not, mind you), where can I find a list of CAs that are able to do this certification for me? Even better would be their websites and/or prices for different service durations. Has anyone here had direct experience getting a driver for a USB microcontroller-based product signed by a CA, who would be able to help me understand and get through the process? I have already posted to the MSDN forums but it seems pretty dead there - It's been two days and my thread only has a handful of views.
usb msp430 microsoft
$endgroup$
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
1
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
1
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53
|
show 6 more comments
$begingroup$
I am developing a product which utilizes an MSP430 microcontroller with a built-in USB module. I obtained a PID from Texas Instruments and used their tools to generate the descriptors, as well as a .inf file to install the driver software. The obvious issue is that due to the custom nature of these files, a popup is presented (on Windows 7) upon plugging in the USB cable that warns the user that the driver is not signed. I believe on Windows 8 and Windows 10 it simply blocks it and does not indicate this to the user at all.
As this is a full-featured product which my company is planning to release, we need to obtain a driver certificate (I believe in the form of a .cat file?) that we can provide to the customer so that they can install the device driver software without issue.
I have been through quite a bit of the Microsoft documentation (most notably this document) trying to get a grasp of what is required in order to get a driver signed, but unfortunately this is over my head at the moment.
This is what I think I understand so far:
- I need to submit my driver (.inf file?) to a Microsoft-authorized certificate authority (CA). There are a number of these out there, so I would need to find one that signs drivers.
- After selecting a CA, generally I will need to pay an annual fee (most commonly for 1, 2, or 3 years) for their service. Any drivers I generate during this time will be permanently signed, even after the service expires. If I want to change the driver or create a new one after the service has expired, I will need to buy service for another 1, 2, or 3 years.
- After paying the fee, the CA will generate a .cat file which is a certificate assuring that the driver I gave them will not be changed. If it does it will no longer match the .cat file and an error will appear during installation
Is this correct? At the risk of sounding like I'm seeking recommendations for specific CAs (I'm not, mind you), where can I find a list of CAs that are able to do this certification for me? Even better would be their websites and/or prices for different service durations. Has anyone here had direct experience getting a driver for a USB microcontroller-based product signed by a CA, who would be able to help me understand and get through the process? I have already posted to the MSDN forums but it seems pretty dead there - It's been two days and my thread only has a handful of views.
usb msp430 microsoft
$endgroup$
I am developing a product which utilizes an MSP430 microcontroller with a built-in USB module. I obtained a PID from Texas Instruments and used their tools to generate the descriptors, as well as a .inf file to install the driver software. The obvious issue is that due to the custom nature of these files, a popup is presented (on Windows 7) upon plugging in the USB cable that warns the user that the driver is not signed. I believe on Windows 8 and Windows 10 it simply blocks it and does not indicate this to the user at all.
As this is a full-featured product which my company is planning to release, we need to obtain a driver certificate (I believe in the form of a .cat file?) that we can provide to the customer so that they can install the device driver software without issue.
I have been through quite a bit of the Microsoft documentation (most notably this document) trying to get a grasp of what is required in order to get a driver signed, but unfortunately this is over my head at the moment.
This is what I think I understand so far:
- I need to submit my driver (.inf file?) to a Microsoft-authorized certificate authority (CA). There are a number of these out there, so I would need to find one that signs drivers.
- After selecting a CA, generally I will need to pay an annual fee (most commonly for 1, 2, or 3 years) for their service. Any drivers I generate during this time will be permanently signed, even after the service expires. If I want to change the driver or create a new one after the service has expired, I will need to buy service for another 1, 2, or 3 years.
- After paying the fee, the CA will generate a .cat file which is a certificate assuring that the driver I gave them will not be changed. If it does it will no longer match the .cat file and an error will appear during installation
Is this correct? At the risk of sounding like I'm seeking recommendations for specific CAs (I'm not, mind you), where can I find a list of CAs that are able to do this certification for me? Even better would be their websites and/or prices for different service durations. Has anyone here had direct experience getting a driver for a USB microcontroller-based product signed by a CA, who would be able to help me understand and get through the process? I have already posted to the MSDN forums but it seems pretty dead there - It's been two days and my thread only has a handful of views.
usb msp430 microsoft
usb msp430 microsoft
edited Dec 19 '18 at 18:40
DerStrom8
asked Dec 19 '18 at 18:21
DerStrom8DerStrom8
13.8k42758
13.8k42758
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
1
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
1
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53
|
show 6 more comments
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
1
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
1
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
1
1
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
1
1
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53
|
show 6 more comments
1 Answer
1
active
oldest
votes
$begingroup$
It's not so bad, actually. I've done this a few times at work, writing and signing an .INF/.CAT for a Microchip PIC24FJ64GB002-based USB CDC-ACM-to-I2C interface.
Establish a relationship with a certificate authority. You will need to provide them some basic information which they will validate. If you go for Extended Validation (EV) they will ask for a lot more, but you shouldn't need to go that far. Thawte, Digicert and Comodo are some examples of CAs.
Purchase an Authenticode code-signing certificate from the CA. This is what you need to sign the .CAT file associated with your .INF file. You don't need a kernel-mode certificate for this level of signing.
Install the certificate (goes without saying)
Download the Windows SDK framework and Windows Driver Kit to get the Microsoft tools needed (catalog generation and signing).
Package and sign the drivers:
- Use inf2cat to generate the catalog (.CAT) file for the .INF file
- Use signtool to sign the catalog file
From this point you could make some sort of driver installer, or use dpinst from the SDK to do basic installation automation.
EDIT: Notes from various comments below:
- Creating an .INF file to load USBSER.SYS is not creating a kernel-mode driver - you are using USBSER.SYS (built-in, signed and trusted already), not creating something new - and as such does not require an EV signing certificate and WHQL certification. A basic Authenticode certificate is all that is needed.
- Starting with Windows 10, you do not need a signed .INF at all for USBSER.SYS devices, as Windows will pick up USB CDC-ACM devices (Class_02) auto-magically. They have also rewritten the driver from scratch and it works much better now (it even handles unexpected device removals and re-insertions without locking up the virtual COM port, which is a huge plus!). That said, you still can use the signed driver approach if you really want to - the signed driver will still 'work'. There are still lots of Win 8.1/8/7 and older machines out there so having a signed driver is still somewhat important for USB CDC-ACM devices.
Further expansion on your questions:
- You do not submit anything for signing to the CA - you purchase the code signing certificate, install it on a machine and do the .INF validation and signing yourself.
- You do not need to pay an annual fee per se - however, the certificate you buy will have either a 1-, 2- or 3-year validity period. When the cert expires you will need to buy a new one to be able to keep signing - anything previously signed will remain valid but you lose the ability to sign new stuff.
- The .CAT is a hash for the .INF - any changes to the .INF will be detected and the certificate will no longer be valid, which means the .INF would behave like an unsigned one.
$endgroup$
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
return StackExchange.using("schematics", function () {
StackExchange.schematics.init();
});
}, "cicuitlab");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "135"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f413050%2fgetting-msp430-usb-driver-signed-by-microsoft%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
It's not so bad, actually. I've done this a few times at work, writing and signing an .INF/.CAT for a Microchip PIC24FJ64GB002-based USB CDC-ACM-to-I2C interface.
Establish a relationship with a certificate authority. You will need to provide them some basic information which they will validate. If you go for Extended Validation (EV) they will ask for a lot more, but you shouldn't need to go that far. Thawte, Digicert and Comodo are some examples of CAs.
Purchase an Authenticode code-signing certificate from the CA. This is what you need to sign the .CAT file associated with your .INF file. You don't need a kernel-mode certificate for this level of signing.
Install the certificate (goes without saying)
Download the Windows SDK framework and Windows Driver Kit to get the Microsoft tools needed (catalog generation and signing).
Package and sign the drivers:
- Use inf2cat to generate the catalog (.CAT) file for the .INF file
- Use signtool to sign the catalog file
From this point you could make some sort of driver installer, or use dpinst from the SDK to do basic installation automation.
EDIT: Notes from various comments below:
- Creating an .INF file to load USBSER.SYS is not creating a kernel-mode driver - you are using USBSER.SYS (built-in, signed and trusted already), not creating something new - and as such does not require an EV signing certificate and WHQL certification. A basic Authenticode certificate is all that is needed.
- Starting with Windows 10, you do not need a signed .INF at all for USBSER.SYS devices, as Windows will pick up USB CDC-ACM devices (Class_02) auto-magically. They have also rewritten the driver from scratch and it works much better now (it even handles unexpected device removals and re-insertions without locking up the virtual COM port, which is a huge plus!). That said, you still can use the signed driver approach if you really want to - the signed driver will still 'work'. There are still lots of Win 8.1/8/7 and older machines out there so having a signed driver is still somewhat important for USB CDC-ACM devices.
Further expansion on your questions:
- You do not submit anything for signing to the CA - you purchase the code signing certificate, install it on a machine and do the .INF validation and signing yourself.
- You do not need to pay an annual fee per se - however, the certificate you buy will have either a 1-, 2- or 3-year validity period. When the cert expires you will need to buy a new one to be able to keep signing - anything previously signed will remain valid but you lose the ability to sign new stuff.
- The .CAT is a hash for the .INF - any changes to the .INF will be detected and the certificate will no longer be valid, which means the .INF would behave like an unsigned one.
$endgroup$
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
|
show 1 more comment
$begingroup$
It's not so bad, actually. I've done this a few times at work, writing and signing an .INF/.CAT for a Microchip PIC24FJ64GB002-based USB CDC-ACM-to-I2C interface.
Establish a relationship with a certificate authority. You will need to provide them some basic information which they will validate. If you go for Extended Validation (EV) they will ask for a lot more, but you shouldn't need to go that far. Thawte, Digicert and Comodo are some examples of CAs.
Purchase an Authenticode code-signing certificate from the CA. This is what you need to sign the .CAT file associated with your .INF file. You don't need a kernel-mode certificate for this level of signing.
Install the certificate (goes without saying)
Download the Windows SDK framework and Windows Driver Kit to get the Microsoft tools needed (catalog generation and signing).
Package and sign the drivers:
- Use inf2cat to generate the catalog (.CAT) file for the .INF file
- Use signtool to sign the catalog file
From this point you could make some sort of driver installer, or use dpinst from the SDK to do basic installation automation.
EDIT: Notes from various comments below:
- Creating an .INF file to load USBSER.SYS is not creating a kernel-mode driver - you are using USBSER.SYS (built-in, signed and trusted already), not creating something new - and as such does not require an EV signing certificate and WHQL certification. A basic Authenticode certificate is all that is needed.
- Starting with Windows 10, you do not need a signed .INF at all for USBSER.SYS devices, as Windows will pick up USB CDC-ACM devices (Class_02) auto-magically. They have also rewritten the driver from scratch and it works much better now (it even handles unexpected device removals and re-insertions without locking up the virtual COM port, which is a huge plus!). That said, you still can use the signed driver approach if you really want to - the signed driver will still 'work'. There are still lots of Win 8.1/8/7 and older machines out there so having a signed driver is still somewhat important for USB CDC-ACM devices.
Further expansion on your questions:
- You do not submit anything for signing to the CA - you purchase the code signing certificate, install it on a machine and do the .INF validation and signing yourself.
- You do not need to pay an annual fee per se - however, the certificate you buy will have either a 1-, 2- or 3-year validity period. When the cert expires you will need to buy a new one to be able to keep signing - anything previously signed will remain valid but you lose the ability to sign new stuff.
- The .CAT is a hash for the .INF - any changes to the .INF will be detected and the certificate will no longer be valid, which means the .INF would behave like an unsigned one.
$endgroup$
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
|
show 1 more comment
$begingroup$
It's not so bad, actually. I've done this a few times at work, writing and signing an .INF/.CAT for a Microchip PIC24FJ64GB002-based USB CDC-ACM-to-I2C interface.
Establish a relationship with a certificate authority. You will need to provide them some basic information which they will validate. If you go for Extended Validation (EV) they will ask for a lot more, but you shouldn't need to go that far. Thawte, Digicert and Comodo are some examples of CAs.
Purchase an Authenticode code-signing certificate from the CA. This is what you need to sign the .CAT file associated with your .INF file. You don't need a kernel-mode certificate for this level of signing.
Install the certificate (goes without saying)
Download the Windows SDK framework and Windows Driver Kit to get the Microsoft tools needed (catalog generation and signing).
Package and sign the drivers:
- Use inf2cat to generate the catalog (.CAT) file for the .INF file
- Use signtool to sign the catalog file
From this point you could make some sort of driver installer, or use dpinst from the SDK to do basic installation automation.
EDIT: Notes from various comments below:
- Creating an .INF file to load USBSER.SYS is not creating a kernel-mode driver - you are using USBSER.SYS (built-in, signed and trusted already), not creating something new - and as such does not require an EV signing certificate and WHQL certification. A basic Authenticode certificate is all that is needed.
- Starting with Windows 10, you do not need a signed .INF at all for USBSER.SYS devices, as Windows will pick up USB CDC-ACM devices (Class_02) auto-magically. They have also rewritten the driver from scratch and it works much better now (it even handles unexpected device removals and re-insertions without locking up the virtual COM port, which is a huge plus!). That said, you still can use the signed driver approach if you really want to - the signed driver will still 'work'. There are still lots of Win 8.1/8/7 and older machines out there so having a signed driver is still somewhat important for USB CDC-ACM devices.
Further expansion on your questions:
- You do not submit anything for signing to the CA - you purchase the code signing certificate, install it on a machine and do the .INF validation and signing yourself.
- You do not need to pay an annual fee per se - however, the certificate you buy will have either a 1-, 2- or 3-year validity period. When the cert expires you will need to buy a new one to be able to keep signing - anything previously signed will remain valid but you lose the ability to sign new stuff.
- The .CAT is a hash for the .INF - any changes to the .INF will be detected and the certificate will no longer be valid, which means the .INF would behave like an unsigned one.
$endgroup$
It's not so bad, actually. I've done this a few times at work, writing and signing an .INF/.CAT for a Microchip PIC24FJ64GB002-based USB CDC-ACM-to-I2C interface.
Establish a relationship with a certificate authority. You will need to provide them some basic information which they will validate. If you go for Extended Validation (EV) they will ask for a lot more, but you shouldn't need to go that far. Thawte, Digicert and Comodo are some examples of CAs.
Purchase an Authenticode code-signing certificate from the CA. This is what you need to sign the .CAT file associated with your .INF file. You don't need a kernel-mode certificate for this level of signing.
Install the certificate (goes without saying)
Download the Windows SDK framework and Windows Driver Kit to get the Microsoft tools needed (catalog generation and signing).
Package and sign the drivers:
- Use inf2cat to generate the catalog (.CAT) file for the .INF file
- Use signtool to sign the catalog file
From this point you could make some sort of driver installer, or use dpinst from the SDK to do basic installation automation.
EDIT: Notes from various comments below:
- Creating an .INF file to load USBSER.SYS is not creating a kernel-mode driver - you are using USBSER.SYS (built-in, signed and trusted already), not creating something new - and as such does not require an EV signing certificate and WHQL certification. A basic Authenticode certificate is all that is needed.
- Starting with Windows 10, you do not need a signed .INF at all for USBSER.SYS devices, as Windows will pick up USB CDC-ACM devices (Class_02) auto-magically. They have also rewritten the driver from scratch and it works much better now (it even handles unexpected device removals and re-insertions without locking up the virtual COM port, which is a huge plus!). That said, you still can use the signed driver approach if you really want to - the signed driver will still 'work'. There are still lots of Win 8.1/8/7 and older machines out there so having a signed driver is still somewhat important for USB CDC-ACM devices.
Further expansion on your questions:
- You do not submit anything for signing to the CA - you purchase the code signing certificate, install it on a machine and do the .INF validation and signing yourself.
- You do not need to pay an annual fee per se - however, the certificate you buy will have either a 1-, 2- or 3-year validity period. When the cert expires you will need to buy a new one to be able to keep signing - anything previously signed will remain valid but you lose the ability to sign new stuff.
- The .CAT is a hash for the .INF - any changes to the .INF will be detected and the certificate will no longer be valid, which means the .INF would behave like an unsigned one.
edited Dec 21 '18 at 14:53
answered Dec 19 '18 at 20:23
Adam LawrenceAdam Lawrence
28.9k24594
28.9k24594
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
|
show 1 more comment
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
4
4
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
$begingroup$
More details: Adafruit's How to Sign Windows Drivers & Executables.
$endgroup$
– CL.
Dec 19 '18 at 20:27
4
4
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
$begingroup$
This is an excellent answer, very helpful indeed. You definitely make it sound much easier than I expected. I will look into this. In the meantime I'm going to accept this answer because of the clear, straightforward steps provided. Cheers!
$endgroup$
– DerStrom8
Dec 19 '18 at 20:37
2
2
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
$begingroup$
@poizan42 This is not a kernal-mode driver. This is a simple USB CDC device which only opens a virtual COM port. No kernal-mode code execution is performed.
$endgroup$
– DerStrom8
Dec 20 '18 at 11:29
1
1
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
$begingroup$
Just wanted to follow up. These steps worked perfectly with just one caveat: inf2cat.exe does not come with the Windows SDK, you have to install the Windows Driver Kit (WDK) as well: docs.microsoft.com/en-us/windows-hardware/drivers/… . Thank you so much for your help, I am now able to install my driver software without any warnings - it shows my company as the publisher as expected
$endgroup$
– DerStrom8
Dec 20 '18 at 23:51
2
2
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
$begingroup$
Answer amended. Thanks for pointing out the obvious (it's been a few years since I installed the toolchains)
$endgroup$
– Adam Lawrence
Dec 21 '18 at 14:53
|
show 1 more comment
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f413050%2fgetting-msp430-usb-driver-signed-by-microsoft%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
Is your driver a fully-featured thing, which needs to execute code in kernel mode, or is it only an inf file? If it is just an inf file, which built-in drivers (.sys files) does it load?
$endgroup$
– Jack B
Dec 19 '18 at 18:47
$begingroup$
This is where I fail, I don't know much about the inner-workings of PCs and how drivers work. My device is designed around an MSP430 with a built-in USB module. This device simply has a CDC interface over the USB connection, so all it does is open a virtual COM port
$endgroup$
– DerStrom8
Dec 19 '18 at 18:51
$begingroup$
As the design sits now, it's actually on a development board and when I try installing the device using the .inf file, I get the standard error from Windows 7: davidegrayson.com/signing/img/win7_unverified_publisher.png . In the meantime for testing I've just been using the .inf and .cat files provided with one of the CDC examples from the MSP430Ware package, but when I release this product I won't be able to do that anymore. If I'm not mistaken, this does not execute code in kernal mode
$endgroup$
– DerStrom8
Dec 19 '18 at 18:53
1
$begingroup$
In short: You can sign that with a normal code signing cert, priced about £80/yr last I looked. No need for all the Microsoft cross-signing stuff. But on Windows 8.1 and earlier it's not super reliable (we couldn't get through EN61326 with it) so you may want to have an alternative lined up too. If no-one beats me to it, I'll write an answer after dinner.
$endgroup$
– Jack B
Dec 19 '18 at 19:14
1
$begingroup$
@AdamLawrence I came back by a few hours later and didn't see that I needed to add anything to your answer. So fine by me.
$endgroup$
– Jack B
Dec 20 '18 at 16:53