.NET Security Blog : Orcas

Disabling the FIPS Algorithm Check

shawnfa — Fri, 14 Mar 2008 17:00:23 GMT

.NET 2.0 introduced a check for FIPS certified algorithms if your local security policy was configured to require them. This resulted in algorithms which are not FIPS compliant (or implementations which were not FIPS certified) throwing an InvalidOperationException from their constructors.

In some cases this isn't a desirable behavior. For instance, some applications need to use the MD5 hashing algorithm for compatibility with an older communication protocol or file format. Prior to .NET 3.5, the AES algorithm was only available in an implementation which was not FIPS certified, and if you needed to use that algorithm the FIPS check could also block you.

To help these cases, we added a configuration file switch to .NET 2.0 SP 1 (and therefore .NET 3.5) which allows an application to say "I know what I'm doing, please don't enforce FIPS for me". For these applications, they can setup a configuration file similar to:

<configuration>

    <runtime>

        <enforceFIPSPolicy enabled="false"/>

    </runtime>

</configuration>

Which will prevent the CLR from throwing InvalidOperationExceptions from the constructor of uncertified algorithms and implementations.

Manifested Controls Redux

shawnfa — Thu, 24 Jan 2008 21:00:00 GMT

Last year, I made a series of posts about a new feature available in the betas of .NET 3.5 which enabled you to specify declaratively the set of permissions that IE hosted managed controls should run with. Since the betas there have been a couple of tweaks to the manifest control model, so those posts need a refresh.

Most notably, the Low Safety (Unrestricted) setting for the Permissions for Components with Manifests URL action is not a part of the final shipping Orcas bits. Instead, the two options are:

High Safety - manifested controls can run with the permissions it requests, but only if those permissions are a subset of the permissions it would have been granted by CAS policy or if the manifests are signed by a trusted publisher.
Disabled - manifested controls may not run at all.

If you're using a machine that had one of the .NET 3.5 betas on it, the Low Safety option will still appear in your Internet Explorer dialog box, however the CLR will treat a value of Low Safety as if it were Disabled.

A lot of times when people look at this feature, they would like a full end-to-end sample of a control in a web page taking advantage of a manifest to elevate its permissions. I've attached a ZIP file containing a sample control to this post.

In order to use this sample:

Create a ManifestControl subdirectory in your wwwroot.
Copy ManifestControl.control, ManifestControl.dll, ManifestControl.dll.manifest, and ManifestControl.html to the ManifestControl directory created in step 1.
Ensure that your web server is setup to allow downloading of .dll, .control, and .dll.manifest files.
Install ManifestControl.cer in your Trusted Publishers certificate store.
Install ManifestControl.cer in your Trusted Root Certification Authorities certificate store. (Once you are done with the sample, the test certificate should be removed from both of these certificate stores)
Navigate Internet Explorer to http://localhost/ManifestControl/ManifestControl.html

Bypassing the Authenticode Signature Check on Startup

shawnfa — Mon, 07 May 2007 21:25:36 GMT

A while back I wrote about the performance penalty of loading an assembly with an Authenticode signature. The CLR will attempt to verify the signature at load time to generate Publisher evidence for the assembly. However, by default most applications don't need Publisher evidence. Standard CAS policy does not rely on the PublisherMembershipCondition, so unless your application will run on a machine with custom CAS policy modifications, or is intending on satisfying demands for PublisherIdentityPermission (taking into mind that FullTrust means FullTrust in v2.0 of the framework), this is wasted startup cost that could be done without.

Obviously if you know your application doesn't need the Publisher evidence, you won't want to pay the cost of having the signature verified. If you download the Orcas Beta 1 bits, you'll be able to take advantage of a feature in the runtime that disables this signature verification. Your application can now opt out of Authenticode signature verification; which will mean that time to load each assembly will improve (therefore leading to an improvement in startup time if your entry point assembly has an Authenticode signature). The tradeoff of course is that assemblies will no longer receive Publisher evidence or PublisherIdentityPermission. Applications which wish to take advantage of this can add the following line to their .exe.config file:

<configuration>

    <runtime>

        <generatePublisherEvidence enabled="false"/>

    </runtime>

</configuration>

Which will prevent the CLR from verifying the Authenticode signatures of any assembly loaded by the application.

Tying your IE Hosted Control to a Manifest

shawnfa — Mon, 12 Mar 2007 17:00:00 GMT

Last week, I talked about the Orcas feature which allows you to provide a manifest to elevate your control's permissions declaratively. We also saw how to generate manifests that would state what permissions your control needs (and the rules associated with those manifests). Now it's time to tie it all together and create an HTML page that has a control and its associated manifests.

Once you've gotten this far, the last step is thankfully pretty painless. A similar syntax to the one used to attach a config file to a control is used to tie a manifest to it. The only change you need to make to your HTML page which already hosts a managed control via the object tag is to add a link in the HTML head section to the manifest:

<html>
    <head>
        <link rel="MANIFEST" href="TemplateControl.control" />
    </head>
    <body>
        <object classid="TemplateControl.dll#TemplateControlClass" />
    </body>
</html>

There you have it! The control hosted in TemplateControl.dll will now be associated with the TemplateControl.control deployment manifest, which points ad the TemplateControl.dll.manifest application manifest. TemplateControl.dll.manifest gives the permission set the control should run with. If the signer of TemplateControl.control is a trusted publisher, and manifested controls have not been disabled from this zone then the control will run with the permissions it asked for.

If this does not work as expected, double check that the manifests are following all of the rules for manifests. You can also check to make sure that the "Permissions for Controls with Manifests" IE security setting is not "disable" (which it is for the MyComputer zone), and that the target machine has Orcas on it. Finally, there's always the IEHost debug log which should list out any errors encountered parsing the manifests.

Manifests for IE Hosted Controls

shawnfa — Fri, 09 Mar 2007 20:50:00 GMT

Earlier this week,I talked about the Orcas feature where controls can declaratively request permissions in a similar way to ClickOnce applications. In fact, the manifests used for this request are the same manifests used for ClickOnce applications, with a few special requirements added onto them. When you're developing controls, its possible to have manifests which don't meet one of these requirements. In that case, the error in the manifest will be logged to the IEHost debug log in order to help you figure out what needs to be changed. Lets dig in deeper to the manifests, since they are really at the heart of this feature.

Like a ClickOnce application, IE hosted controls will have both a deployment and an application manifest. By convention, the deployment manifest will have a .control extension, while the application manifest will have a .dll.manifest extension. Both manifests are required to have a valid Authenticode and StrongName signature (a self signed certificate will work, however it must be installed in the trusted root store on the client machines so that it "chains" to a valid root). Both manifests must also be located on the same site as the control -- a control on foo.com cannot have manifest on bar.com. Similarly, a deployment manifest on bar.com cannot refer to an application manifest on baz.com.

Outside of those common requirements, each manifest has its own specific requirements. Let's look at the deployment manifest first. The requirements for the deployment manifest are:

It must not request to be installed on the local machine. IE hosted controls do not get installed into the ClickOnce application store.
It must have a deploymentProvider which exactly matches the URL it was downloaded from.
Point at the application manifest, and have the correct hash of the manifest included.

I've attached TemplateControl.control as a template that control deployment manifests can be based upon. The first two requirements can be seen in the deployment section of the manifest:

  <deployment install="false">
    <deploymentProvider codebase="http://www.contoso.com/TemplateControl/TemplateControl.control" />
  </deployment>

And the last one is in the dependency section:

  <dependency>
    <dependentAssembly codebase="TemplateControl.dll.manifest" size="1929" dependencyType="install">
      <assemblyIdentity name="TemplateControl.dll" version="1.0.0.0" publicKeyToken="7bbbb9ce54f53dd4" processorArchitecture="msil" language="neutral" type="win32" />
      <hash>
        <dsig:Transforms>
          <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
        </dsig:Transforms>
        <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <dsig:DigestValue>QPq0hc3mZPhWUeRAthX7QefabZk=</dsig:DigestValue>
      </hash>
    </dependentAssembly>
  </dependency>

Onto the application manifest. There are a few more rules around this manifest:

The hash of the application manifest must match the hash specified in the deployment manifest
The entry point must match the control being downloaded
There must be a <hostInBrowser /> tag
A permission set must be supplied
The only file allowed to be listed is the control itself, we do not support having additional files in the manifest. You can of course load them when your control is running, but only the control assembly may appear in the manifest
The control must have its SHA-1 hash listed, and that hash must match the control

Again, I've attached TemplateControl.dll.manifest to this post to use as a template for control application manifests. You can see in the entry point section that the entry point is indeed the control (assuming the control is hosted in TemplateControl.dll), and that it should be hosted in the browser:

  <entryPoint>
    <assemblyIdentity name="TemplateControl" version="1.0.0.0" publicKeyToken="7bbbb9ce54f53dd4" processorArchitecture="msil" language="neutral" />
    <commandLine file="TemplateControl.dll" />
    <hostInBrowser xmlns="urn:schemas-microsoft-com:asm.v3" />
  </entryPoint>

The permission set exists in the trustInfo section, as is the case for regular ClickOnce manifests:

  <trustInfo>
    <security>
      <applicationRequestMinimum>
        <PermissionSet class="System.Security.NamedPermissionSet" version="1" Unrestricted="true" Description="Allows full access to all resources" SameSite="site" ID="FullTrust" />
        <defaultAssemblyRequest permissionSetReference="FullTrust" />
      </applicationRequestMinimum>
    </security>
  </trustInfo>

And the dependency is the control assembly:

  <dependency>
    <dependentAssembly codebase="TemplateControl.dll" size="4608" dependencyType="install" allowDelayedBinding="true">
      <assemblyIdentity name="TemplateControl" version="1.0.0.0" publicKeyToken="7bbbb9ce54f53dd4" processorArchitecture="msil" language="neutral" />
      <hash>
        <dsig:Transforms>
          <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
        </dsig:Transforms>
        <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <dsig:DigestValue>yxh1Z4B1Maw8UoXSU+rDwsj+8bA=</dsig:DigestValue>
      </hash>
    </dependentAssembly>
  </dependency>

Unfortunately, the tools story for creating control manifests isn't all together great at this point. The easiest way that you'll be able to generate these manifests is to start with the template manifests, and then use the Mage tool that ships in the Framework SDK to update and sign them. Since Mage does not yet know about control manifests, there are a few manual steps involved:

Create a directory containing your manifest and control. You may want to edit the manifest at this point, to point it at YourControl.dll rather than TemplateControl.dll. You could also update the other names in the manifest.
Update the hash value of your control: Mage -Update YourControl.dll.manifest
Mage will give a warning about a .dll not being a valid entry point, and insert dependencies on the operating system and CLR. You'll have to edit the manifest so that the extra dependencies are removed.
Sign the manifest: Mage -Sign YourControl.dll.manifest -CertFile <path to your certificate> -Password <certificate password>

At this point you'll have a valid application manifest for your control. Similar steps are required to setup the deployment manifest:

Rename TemplateControl.control to give it a more appropriate name. You'll also need to change the deploymentProvider to point at the URL where your manifest will be accessed by client machines, and update the reference to TemplateControl.dll.manifest to point at your control's application manifest.
Update the hash value of the application manifest: Mage -Update YourControl.control
Sign the manifest: Mage -Sign YourControl.control -CertFile <path to your certificate> -Password <certificate password>

Now you have a pair of valid manifests to use with your control. Yes, I know that this isn't exactly ... well ... the easiest procedure in the world. Hopefully by the time we finish the release we will have a better story here, but for now these steps will allow you to play with generating controls for the CTP releases.

So now we know the overall picture of manifested IE controls in Orcas and have seen what the manifests look like and how to create them, that leaves us with one last step. Next time, we'll take a look at how we hook the whole thing up in an HTML page to get the full story working end-to-end.

[Update 3/29] Provided a link to the TemplateControl.control file

Specifying Permissions for IE Controls in Orcas

shawnfa — Wed, 07 Mar 2007 22:25:00 GMT

One of my most read blog posts (and one of the reasons I created this blog in the first place -- to answer what was one of the most asked questions on the old .NET Security newsgroup), is my post about granting managed controls hosted in IE extra permissions. If you need to have a managed control run above its default grant set, the process getting this working in .NET versions through .NET 2.0 was relatively painful.

You needed to create an extra code group that granted your control the permissions required, and then get that policy deployed to all client machines. One of the more common ways of doing this is to use the .NET MMC snap-in to create a policy MSI file. However, those policy files are snapshots of policy and overwrite any other custom policy settings on each client machine. This means if a user has two controls they use that require an MSI prerequisite, they end up fighting for control over policy -- only the last one installed wins. There's also no guarantee that client machines have run my MSI file, so unless the control does runtime permission checking it will sometimes fail on misconfigured machines.

Versioning provides another challenge here. Since every CLR has independent security policy and IE will always load the latest runtime version when hosting a control, as soon as a new version of the CLR ships all changes in policy will no longer apply to hosted controls, and new MSIs will need to be created.

On top of all of these challenges, is the problem mentioned in the original blog post -- namely that the AppDomain hosting the control will only have Url and Zone evidence. If your code group uses a stronger membership condition (and it probably should) such as StrongName or Publisher, any demands will fail when they hit the AppDomain boundary because the domain will not match your code group and will have lower trust than your assembly. This required adding an assert at each of the control's entry points, which is not really a great coding practice.

With all of these problems, it's pretty obvious that we need a better solution for controls which need to run with higher permission than default. A lot of these problems apply to applications as well as controls, and we solved them in .NET 2.0 by having those applications use ClickOnce. Since ClickOnce applications can specify their required permissions in a manifest and allow the user to decide if this is a safe set of permissions to grant, there was no policy modification.

Orcas introduces a very similar system for IE hosted controls. They can now include a set of manifests, which are very similar to the ClickOnce manifests, that state the required set of permissions for the control to run. Again, this decouples the control from policy which solves the MSI-fight problem as well as the CLR versioning problem. Just like ClickOnce applications, these controls are hosted in simple sandbox domains -- this means that the domain and the control both have the same permission set, removing the need to assert at the entry points.

One of the first questions that comes to mind when thinking about this feature is if a control is allowed to declaratively state what permissions it wants to run with, what's to prevent malicious controls from elevating to FullTrust and doing whatever it wants to my machine? We've decided not to do any prompting of the user for this feature, instead we use a simple algorithm to determine if the control should be allowed to run with its requested permissions. Specifically, if any of these requirements are met, then we allow the control to run:

The control is requesting a subset of the permissions it would have gotten anyway. So if a control is coming from the Internet zone and it is requesting the Internet permission set, we'll allow it to run.
The control is signed by a trusted publisher. The control's deployment manifest must be signed (more on the requirements for manifests later) by a X.509 certificate. If the signer is in the client's trusted publisher list and the certificate is valid and chains to a trusted root, then we allow the control to run with whatever permissions it requests. This is likely the easiest way for IT organizations to make use of the feature, as trusted publishers can be controlled via group policy.
If the zone the manifest is running from explicitly allows controls loaded from it to elevate their permissions

If all three of those checks fail, then the control is not allowed to run. (Note that we don't run the control with the permissions it would be granted from policy if these checks fail -- we assume that the control was authored to run with the specified set of permissions, and should not be run with less than the requested set).

The third check may need a little more explanation. When you install Orcas, you'll see that a new option has been added to the Internet Explorer Security Settings dialog box called "Permissions for components with manifests":

As you can see, there are three possible values for this setting:

Disable - controls with manifests will not be allowed to run at all. Even if the control is requesting only Execution permission and is signed by a trusted publisher, if the zone it's loaded from is set to disabled the CLR will not allow the control to run.
High Safety - controls are not allowed to elevate their permissions via this setting alone. If the control is not requesting elevation or is signed by a trusted publisher than it will be allowed to run, however this setting will cause check #3 above to fail.
Low Safety (Unrestricted) - controls are allowed to elevate. Even if the first two elevation checks fail, if the zone is set to low safety, then the control will be allowed to run with whatever permissions it asks for. The reason that "Unrestricted" appears in the setting is that by setting this value, you're effectively giving all controls loaded from this zone the ability to run fully trusted. Obviously that's not something that should be done lightly if at all. [Updated 1/24/2008 - Low Safety was removed after the Orcas betas.]

Essentially, if the setting for the deployment manifest's zone is High Safety then elevation check #3 fails, if it is Low Safety then elevation check #3 succeeds. The default values for this setting are:

MyComputer	Disable
Local Intranet	High Safety
Trusted Sites	High Safety
Internet	High Safety
Restricted Sites	Disable

So no zone will elevate by default, and manifested controls are disabled entirely on the local machine and restricted sites.

Next time: More information about the manifests

Introduction to the Orcas Add-In Model

shawnfa — Tue, 20 Feb 2007 21:08:29 GMT

One of the features the CLR team is adding in Orcas is that we're providing a new model to help enable your application to host Add-Ins. I've got a special interest in this set of features, as I always try to make my hobby applications pluggable for some reason, and I tend to end up writing a ton of infrastructure that, once Orcas ships, I will no longer have to. The Add-In team has done the work to enable discovery, versioning, and most importantly (from my perspective at least :-) ) securely sandboxing those Add-Ins.

Recently, they've done a pretty big brain-dump of how their feature is going to work. Some of the resources available are:

MSDN Magazine Articles:

Blogs

Jason's blog is interesting because he's decided to go through the steps to upgrade Paint.NET to use the new AddIn model, and discuss his experiences. If you're intereseted in making your apps extensible, it's worth checking out this feature to see if it's made your life any easier.

Elliptic Curve Diffie-Hellman

shawnfa — Tue, 23 Jan 2007 00:58:40 GMT

The second elliptic curve algorithm added to Orcas is elliptic curve Diffie-Hellman, as the ECDiffieHellmanCng class.

This is the first time Diffie-Hellman is available as part of the .NET Framework, so lets take a quick look at what it is and what it does. Diffie-Hellman is one of the oldest asymmetric algorithms, however unlike the other asymmetric algorithms in the framework today, it does not perform encryption or digital signatures. Instead it allows two parties to exchange private key material even if they only can communicate through a completely public channel. (In Network Security: Private Communication in a Public World, an amusing example is given where Diffie-Hellman is performed by two parties taking out ads in the local newspaper).

Key exchange is somewhat of a misleading term, since it implies that one party to the communication generates a key and via the communication protocol lets the other party know what that key is. Instead what really happens is that Diffie-Hellman allows both parties to calculate the same secret value, which is referred to as the secret agreement in the managed Diffie-Hellman classes. This secret agreement can then be used for any number of purposes, including being used as a symmetric key.

Instead of exposing the secret agreement directly however, the ECDiffieHellmanCng class does some post-processing on the agreement before letting the value out. We refer to this post processing as the key derivation function; you can select which KDF you want to use and set its parameters via a set of properties on the instance of the Diffie-Hellman object:

Key Derivation Function	Properties	Meaning
Hash	HashAlgorithm	Hash algorithm to process the secret agreement with
	SecretPrepend	Optional byte array to prepend to the secret agreement before hashing it
	SecretAppend	Optional byte array to append to the secret agreement before hashing it
Hmac	HashAlgortihm	Hash algorithm to process the secret agreement with (using the HMAC version of the algorithm).
	HmacKey	Key used for the HMAC operation
	SecretPrepend	Optional byte array to prepend to the secret agreement before hashing it
	SecretAppend	Optional byte array to append to the secret agreement before hashing it
Tls	Label	TLS PRF Label
Tls	Seed	TLS PRF Seed

The result of passing the secret agreement through the key derivation function is a byte array that may be used as key material for your application. The number of bytes of key material generated is dependent on the key derivation function, for instance SHA-256 will generate 256 bits of key material, while SHA-512 will generate 512 bits of key material.

The basic flow of an elliptic curve Diffie-Hellman key exchange is:

Alice and Bob create a key pair to use for the Diffie-Hellman key exchange operation
Alice and Bob configure the KDF using agreed upon parameters
Alice sends Bob her public key
Bob sends Alice his public key
Using each other's public keys, the secret agreement is generated, and the KDF is applied to the secret agreement generating key material.

In code, this looks basically as you would expect:

ECDiffieHellmanCng alice = new ECDiffieHellmanCng();
alice.KeyDerivationFunction = ECDiffieHellmanKeyDerivationFunction.Hash;
alice.HashAlgorithm = CngAlgorithm.Sha256;
 
ECDiffieHellmanCng bob = new ECDiffieHellmanCng();
bob.KeyDerivationFunction = ECDiffieHellmanKeyDerivationFunction.Hash;
bob.HashAlgorithm = CngAlgorithm.Sha256;
 
byte[] bobKey = bob.DeriveKeyMaterial(alice.PublicKey);
byte[] aliceKey = alice.DeriveKeyMaterial(bob.PublicKey);

After running this code, aliceKey and bobKey are both 32 bytes long and match each other. Now, Alice could use this as a symmetric key:

AesCryptoServiceProvider aes = new AesCryptoServiceProvider();
aes.Key = aliceKey;

Obviously, this example is simplified as both Alice and Bob are unlikely to be running in the same process. ECDiffieHellmanPublicKey, which is the class returned by the PublicKey property is Serializable, so that it may be sent across any remoting channel. It also can be manually converted to and from a byte array and XML, allowing for manual serialization in advanced use cases.

One thing to note about Diffie-Hellman is that it only guarantees that both parties are generating a secret that nobody else knows about. It does not let either party know the identity of the other. For instance, in the above code, Alice cannot be sure that the other person in the conversation is Bob; there could potentially be a man-in-the-middle attack here.

In order to solve that, Alice or Bob could use a well-known public key that is distributed by PKI (you can pass a CngKey to the DeriveKeyMaterial API in this case). You could also use HMAC as the KDF and a key that you know only Alice and Bob share to solve this problem.

Elliptic Curve DSA

shawnfa — Thu, 18 Jan 2007 23:05:00 GMT

Yesterday I gave a quick rundown of all the new cryptographic algorithms available in the Orcas January CTP. Today, let's dive in a little deeper to the first of the elliptic curve algorithms, ECDSA. (ECDSA, along with the rest of the CNG classes in the .NET Framework, is only available on Windows Vista).

ECDSA is an implementation of the digital signature standard using elliptic curves, which makes the ECDsaCng class a sort of cousin of the DSACryptoServiceProvider class. Because DSA and ECDSA are cousins rather than just different implementations of the same algorithm, there is a new base class ECDsa that elliptic curve DSA implementations derive from. You also cannot sign some data with DSACryptoServiceProvider and then verify that signature with ECDsaCng.

Let's take a look at a basic example of using ECDSA:

ECDsaCng dsa = new ECDsaCng();
dsa.HashAlgorithm = CngAlgorithm.Sha256;
 
byte[] data = new byte[] { 21, 5, 8, 12, 2007 };
byte[] signature = dsa.SignData(data);
 
if (dsa.VerifyData(data, signature))
    Console.WriteLine("Verified");
else
    Console.WriteLine("Not verified");

First we create a new ECDsaCng object, which will generate a random key for us to use. Next, we setup the hash algorithm to use on the input data when creating the signature. Finally, we can call SignData to create a signature over a blob of data, and VerifyData to verify that the signature is correct.

There are also SignHash/VerifyHash APIs available -- SignData will essentially just hash the data with the hash algorithm specified on the ECDsaCng object (defaulting to SHA-256) and then do a SignHash on the resulting hash value.

Sidebar: CNG Pseudo-Enums

I showed the HashAlgorithm property in the example, even though I was setting it back to the default value, because it uses the CngAlgorithm class which is the first of several pseudo-enums that will show up when you play with the CNG classes. CNG itself is very configurable, and it takes most of its configuration options as strings. With our managed APIs, we didn't want to limit the set of parameters you can pass to CNG to the set that we had predefined a mapping from a traditional enum to a CNG string for. We also wanted to preserve type safety (having everything be a string makes it unclear which strings can go where), and provide pre-defined values for the common cases.

The result is a set of pseudo-enumerations like CngAlgorithm. CngAlgorithm isn't an enum, it's a class. We've provided a set of CngAlgorithms representing the common algorithm names as static properties, which allow you to use it with enum-like syntax. There's also a CngAlgorithm constructor which takes a string, which means that if you need to use a CNG algorithm that isn't in the list you can construct a CngAlgorithm to reference that algorithm.

Each of the pseudo enums also behave just as you would expect when dealing with them directly. You can compare them with your language of choice's equality comparison operators, get their hash code, and convert them to their underlying strings. In addition to CngAlgorithm other pseudo-enums you'll find are CngAlgorithmGroup, CngKeyFormat, and CngProvider.

The default constructor generates a random key for use with the P-521 curve, described in appendix 6 of FIPS 186-2. There is also a constructor which accepts the curve you wish to work with; currently ECDsaCng supports P-192, P-256 and P-521. Or, if you don't want to generate a random key you can pass in an existing key to the constructor and it will work with that.

Incidentally, the CngKey class is your one stop shop for anything to do with CNG keys (stored by NCrypt). You can use this class to create a new random key, open or delete an existing key, get the properties of a key, import / export the key, etc. We also expose a SafeNCryptKeyHandle which represents the underlying NCRYPT_KEY_HANDLE, allowing you to easily P/Invoke for any other functionality not exposed in the CngKey class itself.

In addition to exporting the ECDSA key via the CngKey property of the ECDsaCng object, you can also export the key into XML. However, since there is currently no standard format for elliptic curve XML, you need to specify which format you want the XML to appear in (not specifying a format will cause an exception). Currently, we only support one option which is the format described in RFC 4050.

So that concludes our whirlwind tour of the ECDsaCng class. Next time we'll take a look at the elliptic curve Diffie-Hellman support in Orcas.

New Crypto Algorithms in Orcas

shawnfa — Wed, 17 Jan 2007 21:21:00 GMT

The January CTP of Orcas is now available, and with it comes a total of 12 new cryptography algorithm implementation classes, which include 2.5 new algorithms. (I'll count AES as 0.5 since we did already have Rijndael :-) ). These classes also are the first set of managed wrappers around the new CNG APIs in Windows Vista, which will use the Cng suffix on the implementation classes.

Dividing the new algorithms up into their types (all in the System.Security.Cryptography namespace in System.Core.dll), this CTP has:

Hash Algorithms

Algorithm	Class	OS Required
MD5	MD5Cng	Windows Vista
SHA-1	SHA1Cng	Windows Vista
SHA-256	SHA256CryptoServiceProvider	Windows 2003
SHA-256	SHA256Cng	Windows Vista
SHA-384	SHA384CryptoServiceProvider	Windows 2003
SHA-384	SHA384Cng	Windows Vista
SHA-512	SHA512CryptoServiceProvider	Windows 2003
SHA-512	SHA512Cng	Windows Vista

The hash algorithms work just as you would expect, and should function as simple drop-in replacements for corresponding algorithms that have already shipped in v2.0 of the .NET Framework. The big advantage here is that these hash algorithms are just wrappers around the Windows implementations of the algorithms, and therefore are FIPS compliant versions of the SHA-2 algorithms which had only managed versions in v2.0. For applications targeting Vista which must use CNG, this set of algorithms also provides CNG wrappers for all of our hashing algorithms.

Symmetric Algorithms

Algorithm	Class	OS Required
AES	AesCryptoServiceProvider	Windows XP SP2
AES	AesManaged	All Supported Platforms

We've provided a new Aes base class for implementations of AES (rather than Rijndael which allows some parameters to be set differently than AES). Two implementations of this base class are shipping with the Orcas January CTP, once which wraps the CAPI implementation of AES and a managed implementation of the algorithm which should run on any platform the CLR supports.

AesManaged is actually just a wrapper around RinjdaelManaged with some code added to make sure that you do not setup the algorithm to operate in a non-AES compatible way. For instance, AesManaged does not allow you to change the block size. (It will also disallow the use of CFB and OFB mode because of the way that RijndaelManaged works with those modes).

Asymmetric Algorithms

Algorithm	Class	OS Required
Elliptic Curve DSA	ECDSACng	Windows Vista
Elliptic Curve Diffie-Hellman	ECDiffieHellmanCng	Windows Vista

These are the really interesting additions to the cryptography libraries in this CTP, the first appearance of elliptic curve cryptography in the .NET Framework. Since these will take more than just a paragraph to cover, the next couple of blog posts will focus on these classes (as well as the other supporting classes to help work with CNG). Up next, Elliptic Curve DSA.

Using Lightweight CodeGen from Partial Trust

shawnfa — Thu, 05 Oct 2006 19:30:00 GMT

Last time I talked about the new Orcas feature allowing you to use reflection from partial trust. Specifically we talked about standard reflection and Reflection.Emit, putting off Lightweight CodeGen until today.

Before we start, if you're new to LCG, you might want to check out Yiru's quick introduction to the feature. If you're planning on doing much work with DynamicMethods, Haibo's excellent VS 2005 DynamicMethod visualizer is highly recommended.

Traditional Dynamic Methods

The v2.0 DynamicMethod constructors took as a parameter either a module or type to host the method. In Orcas, these constructors will no longer demand ReflectionPermission/ReflectionEmit to use. If you've selected to host the dynamic method outside of your assembly, then a demand for ReflectionPermission/RestrictedMemberAccess + the grant set of the target assembly will be done. For compatibility with v2.0, if a demand for SecurityPermission/ControlEvidence would have succeeded then this operation is also allowed. Using the skip visibility feature will still require ReflectionPermission/MemberAccess.

Let's look at a few examples to help clear that up. Lets say a simple sandbox domain is setup with a grant set of Internet + RestrictedMemberAccess. Assemblies A and B containing types TypeA and TypeB are loaded into the domain, along with two host assemblies, HostAssemblyA and HostAssemblyB containing HostTypeA and HostTypeB.

Emitting type	Host target	Success	Reason
TypeA	TypeA	Yes	You can always emit into your own assembly
TypeA	TypeB	Yes	Everything in the domain has RMA + the grant set of Assembly A (so RMA + Internet)
HostTypeA	TypeB	Yes	Everything in the domain has RMA + the grant set of Assembly B
TypeB	HostTypeB	No	In this case, the demand will be for RMA + grant of HostAssembly = FullTrust. This will fail on B's stack frame
HostTypeA	HostTypeB	It depends :-)	This will also trigger a demand for FullTrust, which will be satisfied by HostTypeA but fail when it hits the AppDomain boundary. If HostTypeA asserted for FullTrust before creating the dynamic method this will succeed, otherwise it will fail.

This all boils down to one rule which is very similar to the rule for partial trust standard reflection, specifically you can emit methods into assemblies within your trust level -- however you can not emit methods into assemblies which have more trust than you.

Anonymously Hosted Dynamic Methods

Orcas introduces a new set of constructors which do not allow you to specify the location where the DynamicMethod is hosted and are specially tailored to enable partially trusted code to use LCG -- no demands are made when emitting one of these anonymously hosted dynamic methods.

One of the constructors for anonymously hosted dynamic methods accept a restricted skip visibility flag. If you create your method and do not ask for restricted skip visibility then everything works exactly as you would expect. Namely, your new method can access public members of any type to do its work.

Things are much more interesting when restricted skip visibility is set to true. Generally, restricted skip visibility is the partial trust equivalent of the skip visibility parameter on standard dynamic methods, meaning that the JIT does not do access checks when your method attempts to access various types, fields, methods and properties. This allows dynamically generated code to access private and internal members of types that it would not normally have access to -- which obviously needs to be a protected operation.

If restricted skip visibility is on, then each time a member is accessed that a normal visibility check would prevent, a demand for ... you guessed it, RestrictedMemberAccess + the permissions of the target is done. This demand is done against the call stack which was in place when the anonymously hosted dynamic method was created -- which may or may not be the same as the call stack when it gets JITed.

Another few examples of restricted skip visibility are probably in order. We'll use the same set of types and assemblies as the above examples:

Let's say that TypeA creates an anonymously hosted dynamic methods with restricted skip visibility that accesses a private field of TypeB. This dynamic method is later invoked:

Construction call stack		JIT call stack
HostTypeA.InvokeAddIn	FullTrust	TypeA.OnAddInInvoked	Internet + RMA
TypeA.Initialize	Internet + RMA	TypeA.RunDynamicMethod	Internet + RMA
TypeA.EmitDynamicMethod	Internet + RMA	(DynamicMethod)

When B causes the dynamic method to be JITed, we see an access to a private member of B. Since B has a grant set of Internet + RMA, the resulting demand is also Internet + RMA. This demand is done against the dynamic method construction call stack and succeeds since everybody on the stack has at least Internet + RMA.

In a similar example, the host assemblies might want to access private members of each other. For instance if HostTypeA emits a dynamic method which accesses an internal type in HostAssemblyB:

Construction call stack		JIT call stack
HostTypeA.Initialize	FullTrust	TypeA.OnAddInInvoked	Internet + RMA
(Assert FullTrust)		TypeA.RunDynamicMethod	Internet + RMA
HostTypeA.EmitDynamicMethod	FullTrust	(DynamicMethod)	FullTrust (transparent)

This will also succeed. The JIT will do a demand for RMA + the grant set of the internal type in HostAssemblyB, which becomes a demand for FullTrust. Even though the dynamic method is being JITed and invoked on a call stack where nothing is fully trusted, the demand succeeds because it goes against the call stack when the dynamic method was constructed, which was entirely fully trusted. The assert was necessary to prevent the demand from hitting the partially trusted AppDomain boundary.

Three Simple Rules for Partial Trust LCG

Although the rules for using LCG from partial trust can seem complicated at first, they really boil down to these three main points:

If RMA is granted, you can emit into any assembly at your trust level or lower
Any partial trust code can emit an anonymously hosted dynamic method
If RMA is granted, your anonymously hosted dynamic method can also use restricted skip visibility to skip JIT time visibility checks against members at your trust level or lower

RestrictedMemberAccess

shawnfa — Fri, 29 Sep 2006 19:19:00 GMT

The September CTP of Orcas went live last night, including lots of features that other MSDN blogs are buzzing about such as LINQ to Objects, partial C# 3.0 support, and partial VB 9.0 support. (And prompting me to create the new Orcas category to replace the defunct Whidbey category).

However, my favorite feature available in the CTP is down at the bottom of the description:

Reflection in Partial Trust, enabling sand box scenarios for all applications that depend on these features

Yep, reflection is now available in partial trust!

So, what exactly is this feature? It's easier to consider how it affects the three major portions of reflection:

Reflection.Emit
Reflection
DynamicMethods

Reflection.Emit is the easiest of the group. ReflectionPermission/ReflectionEmit is no longer demanded when you try to emit an assembly. If you try to write the assembly to disk obviously you need FileIOPermission (and for obscure reasons ReflectionEmit to write out debug symbols), but a standard in-memory assembly can be emitted by any assembly with any permission set. The newly emitted assembly will run with the same permissions as the assembly which emitted it.

Standard reflection is also relatively straight forward. There is now a new flag on ReflectionPermission, RestrictedMemberAccess, which should be granted to any assembly which needs to have access to reflection in partial trust. When some partial trust code attempts to use reflection to access a member which it would not be able to access via standard visibility rules, the CLR will now demand the grant set of the target object plus RestrictedMemberAccess.

For instance, assembly A and B are both part of the same AddIn, and are hosted in a simple sandbox domain granting them the Internet permission set and RestrictedMemberAccess. If a method in assembly A tries to use reflection to invoke a private method in assembly B, the CLR will demand:

Target Permissions union RestrictedMemberAccess =
B's permissions union RestrictedMemberAccess =
Internet + RestrictedMemberAccess

The call stack at this point might look like this:

AppDomain Boundary Internet + RestrictedMemberAccess

HostAssembly AddInManager.LaunchAddIn FullTrust

A AddIn.Run Internet + RestrictedMemberAccess

A AddIn.InvokePrivateMethodOnB Internet + RestrictedMemberAccess

As the demand for Internet + RestrictedMemberAccess proceeds up the call stack, it will succeed at each frame, and therefore A will be allowed to invoke a private method in B.

Now, suppose A tries to invoke an internal member in an assembly that's part of the host application, say Host.EraseAllUserData(). In this case, the CLR will demand:

Target Permissions union RestrictedMemberAccess =
Host assembly permissions union RestrictedMemberAccess =
FullTrust union RestrictedMemberAccess =
FullTrust

By looking at the call stack above, we can see that the demand for FullTrust will fail as soon as it hits the first frame, since A is not fully trusted.

The reverse scenario will succeed ... if the host assembly tries to reflect into A, the demand for Internet + RestrictedMemberAccess will again succeed at all points on the call stack, allowing the host access to both A and B. (Notice though that if a host assembly attempts to reflect on private members of another fully trusted assembly it would have to Assert for FullTrust first, since the resulting demand would fail when it hit the AppDomain boundary).

What this boils down to is that any assembly granted RestrictedMemberAccess will be able to reflect on any assembly granted either the same set of permissions it has or a subset thereof. For compatibility reasons, reflection demands will also succeed if the call stack was granted MemberAccess.

Next time, partial trust reflection and dynamic methods ... until then, have fun playing around with the CTP over the weekend! :-) [By the way, this is even easier to do now, since the download page has included Virtual PC images with the CTP already installed].

	AppDomain Boundary	Internet + RestrictedMemberAccess
HostAssembly	AddInManager.LaunchAddIn	FullTrust
A	AddIn.Run	Internet + RestrictedMemberAccess
A	AddIn.InvokePrivateMethodOnB	Internet + RestrictedMemberAccess