Can't sign scripts or open PowerShell Studio Options when Windows is in FIPS mode

[QvicesHg1651163019]

Product, version and build: PowerShell Studio 2017 5.4.139
32 or 64 bit version of product: 64 bit
Operating system: Windows 10 Enterprise build 1607
32 or 64 bit OS: 64 Bit
PowerShell Version: 5

My workstation has recently had FIPS mode enabled as part of a pilot group for compatibility testing. Since then, I cannot sign scripts in PowerShell Studio, and I also can't even open the Options screen. Prior to FIPS being turned on, this all worked as expected.

When trying to sign scripts, I get the following message in the Output window:
This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

When I try to open File -> Options, I get an unhandled exception window (full exception text in the attachment).

Obviously one of the modules being used for script signing is not among the FIPS-validated modules. I can however successfully use Set-AuthenticodeSignature from a PowerShell console. Besides disabling the FIPS registry key before every time I run PowerShell Studio, is there some other resolution for this? Or something in the product roadmap to be resolved?

Thanks.

[Alexander Riedel]

We will have to look into that. According to your log it complains about the Rijndael algorithm, which is another name for AES, which is part of FIPS:
"In the United States, AES was announced by the NIST as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001.[7] This announcement followed a five-year standardization process in which fifteen competing designs were presented and evaluated, before the Rijndael cipher was selected as the most suitable (see Advanced Encryption Standard process for more details).
AES became effective as a federal government standard on May 26, 2002, after approval by the Secretary of Commerce. AES is included in the ISO/IEC 18033-3 standard. AES is available in many different encryption packages, and is the first (and only) publicly accessible cipher approved by the National Security Agency (NSA) for top secret information when used in an NSA approved cryptographic module (see Security of AES, below)."

Script signing uses standard Windows API calls, so I am not sure at the moment what can be done to alleviate this. Using Microsoft software or parts of the OS (as in Powershell) as comparison is tricky, because obviously Microsoft is getting exceptions.
Please also see https://www.howtogeek.com/245859/why-yo ... n-windows/
Are you required to run in FIPS mode (which is FIPS 140) because you work for the U.S. government?

[QvicesHg1651163019]

We will have to look into that. According to your log it complains about the Rijndael algorithm, which is another name for AES, which is part of FIPS:

Script signing uses standard Windows API calls, so I am not sure at the moment what can be done to alleviate this. Using Microsoft software or parts of the OS (as in Powershell) as comparison is tricky, because obviously Microsoft is getting exceptions.

Regardless of the algorithm, applications have to be using one of the FIPS-validated (validated is different than compliant) cryptographic modules to operate in FIPS mode. Likely, the .NET cryptographic provider that PSS is using is not one of the validated modules. From https://technet.microsoft.com/en-us/lib ... aspx#IDISD:
"If you are developing your application using .NET instead of using the native libraries, then setting the FIPS local policy flag will generate an exception when an improper .NET class is used for cryptography (i.e. the cryptographic classes whose names end in "Managed"). The names of these allowed classes end with "Cng", which use the CNG binaries or "CryptoServiceProvider", which use the legacy CAPI binaries."

And from https://cketkar.wordpress.com/2013/05/1 ... et-crypto/:
"In the land of .NET, there are many ways to perform AES encryption, unfortunately, not all of them are FIPS compliant.

• AESCryptoServiceProvider in the System.Security.Cryptography module: This class uses Windows CryptoAPI (CAPI) which uses RSAENH.DLL which is FIPS-compliant. In the .NET world, this is the best option for using AES in any mode of operation (e.g. CBC, CFB, OFB).
• RijndaelManaged in the System.Security.Cryptography module: This module is not FIPS compliant. However, this class can be used to perform AES encryption in CBC mode only if the block-size is set to 128 bits and key length is in {128, 192, 256} bits. Due to feedback size issues, this class cannot be used to perform encryption in CFB/OFB modes. In essence, do not use this class unless you want to support block-sizes other than 128 bits.
• AESManaged in the System.Security.Cryptography module: This is just a wrapper for the RijndaelManaged class where the block-size is fixed to 128 bits. Obviously, this is not FIPS compliant and is only good for the CBC mode encryption of AES. As anticipated, it does not support the feedback size and therefore cannot be used for CFB or OFB modes of AES. Do not use this class."

Are you required to run in FIPS mode (which is FIPS 140) because you work for the U.S. government?

We do federal contract work, and yes our compliance department is requiring FIPS mode to comply with NIST 800-171 rules, thus the compatibility testing we're doing.

[Alexander Riedel]

Ok, thanks for the added information. We will look into it as soon as we can.

[QvicesHg1651163019]

I just noticed 5.4.140 was released and contains a fix for the FIPS crash. That did the trick - I can now open my Options screen again, and sign scripts. Thanks!!