Code signing in a remotely working team?

[dummzeuch 1506]

6 hours ago, Kas Ob. said:

this means any singing developer can have a glance

YMMD: I just imagined the developers singing while running the signing process.

[chillefeld 1]

On 10/1/2024 at 2:08 AM, Vincent Parrett said:

No, that would be terribly wasteful - we calculate the digest on the client and send that to the server to be signed. 

I am curious how this will work with timestamp signing.

Will the server have to perform all the timestamp requests or can this be done client side too?

[Vincent Parrett 754]

30 minutes ago, chillefeld said:

I am curious how this will work with timestamp signing.

Will the server have to perform all the timestamp requests or can this be done client side too?

Timestamping happens on the client - just like with signtool, you specify the timestamp server url and digest algorithm - we caclulate the file digest, send that to the server, get back the signed digest/signature etc, apply that the the file and then perform the timestamp operation (simplified - quite a bit to it in reality). 

This is the command line interface (subject to change)

 

We are using Signotaur to sign itself, here's an extract from the build log - running the sign command

"C:\Program Files\VSoft Technologies\Signotaur\ClientTool\SignotaurTool.exe" sign --apikey ********** --thumbprint 56DFCD0B0C37DD1B9AB75FFCAB6627745E6E93B6 --signServer https://ciagent005:91 --file-digest SHA384 --tr http://timestamp.digicert.com --td SHA256 --allow-untrusted  E:\CI_AWS\Ws\18154\Output\**\*.exe"

and the output (logging needs some tuning). 

 

SignotaurClient
Version : 1.0.0.182
© 2024 VSoft Technologies Pty Ltd
12:19:33 Fetching public key
12:19:33 Sending sign request to server...
12:19:36 Server responded : "Digest Signed OK"
12:19:36 "E:\CI_AWS\Ws\18154\Output\Client\win-x64\SignotaurTool.exe" signed.
12:19:36 Sending sign request to server...
12:19:38 Server responded : "Digest Signed OK"
12:19:39 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.Signotaur.Server.exe" signed.
12:19:39 Sending sign request to server...
12:19:41 Server responded : "Digest Signed OK"
12:19:41 "E:\CI_AWS\Ws\18154\Output\Server\win-x64\VSoft.SSLCertificate.Tool.exe" signed.
12:19:41 Returning result code: 0.
12:19:41 Result from Windows signing API "Operation successful."
Exit code: 0

So signing and timestamping takes around 1-3 seconds per file (depends on file size etc).  

Edited October 2 by Vincent Parrett

[chillefeld 1]

Looks awesome.

We need to renew our certificate in a couple of months so i hope it will be usable by then

[A.M. Hoornweg 144]

On 9/30/2024 at 3:27 PM, Anders Melander said:

...once they have signed in with an USB token.

I don't think you can get around the requirement for the signer to have some kind of physical identification device.

That's not what I read:

 

"DigiCert KeyLocker is a cloud-based service that helps you generate and store the private key without a physical HSM (Hardware Security Module). It was developed to reduce certificate administrators’ efforts and strengthen private key security."

 

 

 

(https://signmycode.com/blog/what-is-digicert-keylocker-everything-to-know-about)

Edited October 2 by A.M. Hoornweg

[Kas Ob. 121]

39 minutes ago, Vincent Parrett said:

This is the command line interface (subject to change)

Nice ! 

 

Few thoughts :

1) Albeit there is no mention for Remove/Delete a signature in Microsoft documentation in three different places for SignTool

https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/signtool

https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe

https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool

The command "remove" is useful and pretty needed, sometimes it is essential, example, you want to switch form internal debugging/testing signature to release, and don't want to ship with your organization internally issued signatures and its certificate, so remove/delete is needed, and it is there within SignTool.exe, i remember have seen in the documentation in the past !

 

2) With SignTool there is "/ac" option for the Sign command, this one can be crucial for new CA certificates, as best practice dictate to include the chain of trust path excluding the root, root must not be included as it will be considered waste and manipulation (root should be presented and trusted by different source like OS store or any higher/adequate administrative authority), but CAs between end point and root can be the line between verification and failure, including the chain of trust is essential for old systems and/or new CAs, so you might need to consider to add it.

 

3) Identifying or choose the certificate by thumbprint is OK, but i would suggest to use similar method like SignTool and IIS, by adding "IssuedTo/SubjectName", this will minimize the hustle of update thumbprint on client/terminal side when more than 1 certificate do exist, as they will exist, like generally you order new certificate while the soon to expired still there, if you look at IIS, it always select the newer certificate after filtering the available certificates with Subject Alternative Name match the domain name, same for sign tool does the same by "/n" option and looking for the SubjectName, so adding this also make sense.

 

Well, this comes to mind and thank you again !

[Kas Ob. 121]

On side note:

I never saw "/ph" and "/nph" being used, and honestly don't know what exactly they do, only can imagine or assume,

 

If you have any resources on this, i would appreciate sharing !

[Anders Melander 1795]

1 hour ago, A.M. Hoornweg said:

That's not what I read

No, I can't see it from the sigmycode site either.

I'm positive that I read somewhere on the digicert site that you had to use 2-factor-authentication using a USB token but I could very well have misunderstood the context.

[Vincent Parrett 754]

2 hours ago, A.M. Hoornweg said:

DigiCert KeyLocker is a cloud-based service

Be aware that most of those cloud based services either charge per signing or impose monthly limits on the number of signings. 

[Vincent Parrett 754]

2 hours ago, Kas Ob. said:

1) The command "remove" is useful and pretty needed, sometimes it is essential, example, you want to switch form internal debugging/testing signature to release, and don't want to ship with your organization internally issued signatures and its certificate, so remove/delete is needed, and it is there within SignTool.exe, i remember have seen in the documentation in the past !

We'll look at this. I haven't seen any api's to make this easy, so will likely have to resort to manipulating the PE file.  That said, if you sign without using the -as option I think it will replace the existing certificate - I will have to test that. We are planning on adding a timestamp command but that is not yet implemented (mostly because we haven't gotten to it yet). 

 

2 hours ago, Kas Ob. said:

2) With SignTool there is "/ac" option for the Sign command

Should be simple to add - I had it in there originally but couldn't figure out why it would be needed - signtool doco doesn't say much

 

2 hours ago, Kas Ob. said:

3) Identifying or choose the certificate by thumbprint is OK, but i would suggest to use similar method like SignTool and IIS, by adding "IssuedTo/SubjectName"

We went around in circles with this, we needed something unique to identify the certificate - IssuedTo/SubjectName is not unique if more than one token is enabled (ie old cert and new cert).   I'll talk to the lead dev about this when he is back from vacation next week - I did the initial r&d and then handed the project off to another dev to make it into a product and this is one of the areas he worked on.  

Thanks for the feedback. 
 

[Vincent Parrett 754]

2 hours ago, Kas Ob. said:

On side note:

I never saw "/ph" and "/nph" being used, and honestly don't know what exactly they do, only can imagine or assume,

 

If you have any resources on this, i would appreciate sharing !

I have never seen it used and couldn't really find any doco on it either, but since they were easy to implement we added it anyway 🤷‍♂️

[Vincent Parrett 754]

Hi All
 

As I mentioned previously, we have been working on a Code Signing server product that makes codesigning remotely really easy. I posted another thread with the details.

 

 

[FredS 138]

On 10/2/2024 at 12:47 AM, Kas Ob. said:

On side note:

I never saw "/ph" and "/nph" being used, and honestly don't know what exactly they do, only can imagine or assume,

 

If you have any resources on this, i would appreciate sharing !

/ph - Page hash enforcement verifies the signature on each page of the executable file as it loads into memory, this attaches the cross chain certificates

[Kas Ob. 121]

14 hours ago, FredS said:

/ph - Page hash enforcement verifies the signature on each page of the executable file as it loads into memory, this attaches the cross chain certificates

Yes, i got that and in fact this is visible when you verify, you can get the full of hash table like this

 

But my question is Why and How is this useful ?

while i found how to build it manually and also verify it, my question is how is this a useful thing, what is the point to hash each page alone when signature is only depend on the the file hash in full, meaning if a page has different hash means that page is tempered with, but this also will change the file hash and render the signature invalid.

 

i asked if someone has saw it in the wild being requested or needed, my assumption is this feature could be one of futuristic feature that being dropped, or it might be still active and hidden (undocumented) by Microsoft, to validate page integrity for already loaded binary, in other words to make it easier and faster for lets say Windows Defender to validate specific pages instead of keeping calculating the whole memory layout of the loaded file, also while not all pages on the file would be in the memory loaded, but this could give the ability to check protected pages for loaded binary if the protection being changed, hence can be way faster to detect tempering while remove the need to pre-calculate these hashes at the loading moment, but yet again DEP should prevent this, unless it is a feature to allow to patch memory pages in safely method (API), yet not documented.

 

Anyway... that too much ranting.

[Vincent Parrett 754]

I have never seen page hashing even mentioned before I started working on our product. I doubt many people even know about it - there is almost no documentation on it other than the signtool command line page . I added it to our client tool because I signtool has it 🤷‍♂️

[rvk 33]

5 hours ago, Vincent Parrett said:

I doubt many people even know about it - there is almost no documentation on it other than the signtool command line page .

If you need IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY flag (which seems to be required in some cases) then you do need it.

For example Windows kernel drivers (??).

 

Quote

Use the /ph option with SignTool
During both test signing and release signing, you must use the /ph (page hash) flag with SignTool when signing user mode binaries with the IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY flag set. On Windows 7 and Windows Server 2008 R2, page hashes are optional, but recommended for performance reasons. The /ph option requires the computer used to sign target files to be using Windows Vista, Windows Server 2008 or later OS versions. Page hash enforcement verifies the signature on each page of the executable file as it loads into memory.

https://learn.microsoft.com/en-us/archive/technet-wiki/255.forced-integrity-signing-of-portable-executable-pe-files

[FredS 138]

8 hours ago, Kas Ob. said:

But my question is Why and How is this useful

This dates back a while, pretty sure some cross certificate (driver signing) issuer supplied this as part of an example on how to sign.a driver.

I only recall because I had to remove it when we stopped cross signing everything.