Working with Signed Assemblies

Shield fully supports protecting signed .NET assemblies while preserving their digital signatures or applying new signatures after protection.

Understanding Strong Name Signing

Strong name signing provides assemblies with a unique identity and guarantees their integrity. A signed assembly includes:

• A public key that uniquely identifies the publisher
• A digital signature created with the corresponding private key
• Protection against tampering (any modification invalidates the signature)

When an assembly is protected with Shield, its IL code and metadata are modified, which would normally invalidate the strong name signature. Shield handles this challenge in two ways:

1. Automatic re-signing: Shield can automatically re-sign the assembly after protection
2. Delayed signing support: Shield works with delay-signed assemblies, allowing final signing later

Protection Process for Signed Assemblies

When Shield protects a signed assembly, it follows this process:

1. The original signature is removed before protection is applied
2. Shield applies all selected protections to the assembly
3. If auto-signing is enabled, the assembly is re-signed using the provided key
4. If delayed signing is used, the assembly is prepared for later signing

Configuration Options

All signing configuration is done through the shield.config.json file. Shield provides several properties to handle different signing scenarios.

Strong Name Signing Properties

Enhanced Signing Properties

Configuration Examples

Standard Strong Name Signing

To configure Shield to re-sign your assembly after protection, use this configuration:

{
  "SignFilePath": "path/to/your/keyfile.snk"
}

Password-Protected Key File

If your key file is protected with a password:

{
  "SignFilePath": "path/to/your/keyfile.snk",
  "SignFilePassword": "your-password-here"
}

Delayed Signing

For delay-signed assemblies where you have the public key but not the private key:

{
  "SignPublicFilePath": "path/to/public.key",
  "DelaySignature": true
}

Enhanced Signing

For additional security with enhanced signing:

{
  "SignFilePath": "path/to/your/keyfile.snk",
  "SignSignatureFilePath": "path/to/signature.file",
  "SignSignaturePassword": "signature-password"
}

Best Practices

• Keep separate keys: Use different strong name keys for development and production
• Secure your key files: Never include private key files in source control
• Test thoroughly: Always verify that the protected and signed assembly works correctly in all scenarios
• Versioning: When re-signing assemblies, consider the impact on assembly binding redirects

Troubleshooting

Common Issues

Assembly fails verification after protection

• Ensure your key file is valid and accessible
• Check that the path to your key file is correct in the configuration

Referenced assemblies can't find the protected assembly

• Verify that the public key token remains the same after protection
• Check assembly binding redirects if using different versions

"Key not valid for use in specified state" error

• Your key file might be corrupt or have incorrect permissions
• Try regenerating the key file using sn.exe

Compatibility

Shield's signing support works with all .NET frameworks and project types. Whether you're protecting libraries, applications, or modules, Shield preserves or reapplies signatures as needed.