Hello folks! If you are longing for CryptoAPI stuff here, then you are on the right page. Here you will see another bunch of CryptoAPI, PowerShell and p/invoke hardcore.

Today’s subject is to convert PFX file to PEM format. A time ago I wrote a function that does opposite — converts PEM to PFX: How to convert PEM file to a CryptoAPI compatible format. Read this post to get information about CryptoAPI structures and ASN modules for PKCS#1 and PKCS#8 structures.

The script below performs the following tasks:

1. Reads certificate or certificate file. If the file is not valid PFX or certificate hasn’t associated private key, an exception will be thrown.
2. Acquires private key (via unmanaged function calls) and attempts to export raw private key from CSP. If the private key is not marked as exportable or it is stored on smart card, an error will be thrown.
3. Inspects CryptoAPI private key blob as described here: RSA/Schannel Key BLOBs, removes header, reads raw private key and splits it to components (modulus, primes, exponents, coefficient). Each component is stored in separate variable.
4. Generates required ASN structures according to output type by using basic ASN encoder.
5. composes certificate and private key and saves them to file.

3 years ago a friend of mine asked me about how to enhance FCIV.exe utility functionality with PowerShell. Microsoft is not developing this tool anymore and you have to write your own tools or wrappers for fciv.exe to get required functionality.

I decided to write completely new tool from scratch by using only native PowerShell code. First version of PsFCIV was released about 3 years ago only for Russian-language audience. However there are many requests from English-language visitors. For example, users request new hashing algorithm support (SHA2 family) and other checking options, like file size and last modification timestamp checking. I made a lot of performance and reliability improvements, so new version works much faster than PsFCIV 1.0. Also I added support for SHA2 hashing algorithms. As the result, I was able to release a new updated PsFCIV 2.0 tool on TechNet Gallery:

Hello folks, CryptoGuy is here again. Today I’ll talk about the most common ways to violate default SRP configurations and how to protect SRP against them.

System folders with write access

It is generally correct that regular users haven’t write permissions on system folders and we can safely allow to run any program from these folders (C:\Windows). However this statement is not fully correct. This is because there are folders where regular users have write and execute permissions. There are at least two default folders:

1. System temp folder: C:\Windows\Temp
2. Print spooler folder.

Here is a screenshot of Temp folder ACL:

Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.

When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).

Multiple policies

The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins:

Today we will talk about rule types, their characteristics and some best practices.

When we open Additional Rules section, we will see two predefined rules:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

They doesn’t look as usual path rules, instead they refer to registry keys. If you open Regedit and check these keys you will see that registry key values contains corresponding folders paths: C:\Windows and C:\Program Files. This means that SRP can read file paths from registry keys and values. In the default state, SRP allows to run anything that is stored in system folders and anything from other folders (say, from user profile) is prevented. In most cases it is enough. However, certain business applications are not installed in the default program folders (C:\Program Files). for example, they can be installed in the system drive root, different drive or in the network folder. As the result, you may have to create additional rules.