Digital Rights-Compliant Applications

MicroStation loads only digital, rights-compliant applications in a file that has limited rights. This section explains how the author certifies an application as rights-compliant and how applications are screened at runtime.

File Protection allows for the use of rights-compliant applications developed outside of Bentley, while preventing non-compliant MDL applications from circumventing rights enforcement. A compliant MDL application checks for digital rights and does not perform any unauthorized functions, such as printing, exporting, or modifying. Many MDL applications, including pre-existing applications, are compliant because they do not perform restricted functions. Other applications have to be changed to become compliant. Rather than trying to prevent illegal operations, MicroStation refuses to load a non-compliant MDL application when less than unlimited rights are granted. Thus, the user can safely use compliant applications and has no access to non-compliant ones.

Bentley has certified the applications that ship with MicroStation. Bentley cannot certify applications developed by others. It is up to the author to certify non-Bentley applications as rights-compliant. Once an application is certified, it is designated as being digital rights-compliant. An application is digital rights-compliant if it is:

• digitally signed

• its signature is verified

• the signing key is either Bentley´s signing key or is a key identified by the author

MicroStation recognizes digital rights-compliant applications by the public keys used in their signatures. Keep in mind that the author identifies the signing keys rather than applications. MicroStation treats any application that was signed using a specified signing key as rights-compliant. Therefore, the author must be careful to guard the signing certificate and only use it to sign rights-compliant applications.

The digital signature prevents anyone from modifying an application after it has been certified and signed by the author. File Protection allows multiple authors to sign the same application without invalidating each other´s signatures. A signed application can also be modified and then re-signed. If an application has multiple signatures, MicroStation recognizes the application as digital rights-compliant if it can verify and recognize any one of them.

If an author adds a signature to an application, he must distribute the affected .MA files to users. In most cases, an author will rely on the original software publisher to sign the application files and simply cite the publisher´s key.

The author uses the rsign and checksignature command-line programs to mark an application as trusted. These programs computes the digital signature of the .MA file and then stores the signature inside the file. MicroStation .MA files have the capacity to store up to about 100 digital signatures internally. Adding a new digital signature to a signed .MA file does not invalidate existing signatures. This means that up to 100 different authors can independently sign the same .MA.

The syntax of the rsign command is:

rsign [-flags] <filename>

Flags to identify the signing certificate:

Flag	Description
<filename>	Identifies the file to signs
-spc <file>	file containing encoded software publishing certificate
-sp <policy>	Add the certification path (chain) or add the certification path excluding the root certificate (spcstore): <chain|spcstore> default to spcstore
-s <location>	Location of the cert store in the registry: <localMachine|currentUser> default to currentUser
-k <KeyName>	Key container name (in current user´s default keystore) where private key can be found
-cn <name>	The common name of the certificate
-v <pvkFile	Pvk file name containing the private key (in case certificate does not specify container or pvk file)

The —sp argument allows the signer of an application to store more information in the digital signature about their identity making it easier for other users to verify their signature. Storing this information takes up more space in the signature section of the application. This section is 50,000 bytes in size. Each signature in the signature chain takes up space so you may be limited in the number of these signatures you can store.

Flags to modify the result of signing:

Flag	Description
--iN	Include the signer´s name in the signature for display purposes.
--iKNDLC	Information to include in the digital signature: K – public key N – certificate common name D – today's date L – name of this computer C – a copy of the certificate
-a <algorithm>	Hashing algorithm for signing: <md5|sha1> Default to sha1
-sha1 <thumbPrint>	The sha1 hash of the certificate (to be used instead of –cn, in case name is not unique)

Miscellaneous flags:

Flag	Description
--r	remove existing signature

The syntax of the checksignature command is:

checksignature [-flags] <filename>

Flags to identify the signature being checked:

Flag	Description
<filename>	Identifies the file to check. If not specified, filename is read from stdin
--l[l]	List (-ll for verbose)
--x	Verify signatures
--xb	Verify that file is signed by Bentley
--n <filename>	List of Bentley applications that are known to be non-rights-compliant
--e <filename>	Export certificates from signatures

The – e argument allows a user to extract the signer's certificate or certification chain from the digital signatures in an application. Standard tools, such as the Microsoft certmgr.exe program can be used to examine and check the certificates for trustworthiness.

Any certificate that has a private key can be used to sign an MDL application. Certificates may be selected from the current user´s certificate store or from standard X.509 certificate (.cer) files and from PKCS#7 (.p7b) files. You can use the Windows Internet Options > Content > Certificates dialog to review your certificate store. The author must distribute the signed .MA to users. A signed .MA file can be used in earlier versions of MicroStation and in non-protected files.

.PFX and .P12 files are not supported.

Identifying signed applications

Use the File > Protection > Applications command to view, add, and remove certificates that identify digital rights-compliant applications .

The Compliant Applications Add command allows the author to choose a certificate that has was used by rsign to digitally sign applications that were digital rights-compliant. You can identify any number of certificates that MicroStation should use to recognize rights-compliant certificates in a given protected file. If another party signed the application(s), you must obtain a copy of the signer´s certificate in order to enter it into the file.

To add a certificate that identifies a rights–compliant application

1. From the File menu´s Protection submenu, choose Applications.
   The Trusted Applications dialog opens.




2. Select the certificate(s).
   MicroStation should use to recognized rights-compliant applications in a protected file.




3. Click the Add trusted signing certificate icon.
   The Add Trusted Signing Certificate dialog opens.




4. Select a digital certificate from his personal certificate store.
   or
   Select a signed e-mail message file (.msg) or a certificate file (.cer or .p7)




5. (Optional) Enter a date the certificate expires.




6. Click OK.
   A rights-compliant certificate is added to the file.

The PROTECT COMPLIANT {ADD|DELETE} command can also be used to add or remove a digital certificate from the list of authorized applications

To add a public key token to a list of authorized .NET assemblies for use with a protected file

1. From the File menu´s Protection submenu, choose Applications.
   The Trusted Applications dialog opens.




2. To add a public key token for a specific .Net assembly, click the Add trusted .Net assembly icon.
   or
   To add a public key token for a specific .Net assembly and all others signed in the same way, click the Add all .Net assemblies signed like this icon.
   The .Net assemblies dialog opens.




3. Navigate to the desired .Net assembly and click Open.
   The trusted application now displays in theTrust applications dialog. The example below shows an individual .Net assembly and an example of all .Net assemblies of the same type.

You can use thePROTECT STRONGNAME {ADD|REMOVE} {ASSEMBLY|PUBLICKEYTOKEN} <assemblyFileNameOrHexPublickeyToken> to add or remove a public key token to/from the list of applications that are authorized for use with the active (protected) file.