1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
|
* Cryptography
In the .NET framework cryptography can be found under a number of
namespaces in several assemblies.
** Assembly: corlib
*** Namespace: <b>System.Security.Cryptography</b>
Thanks to the work of many people this namespace is almost complete.
**** Status
<ul>
* Every classes are present.
* Most classes have their unit tests. Some tests like <code>
SymmetricAlgorithmTest</code> are generated by an external
tool.
</ul>
**** TODO
<ul>
* The current implementation of <code>CryptoStream</code> is
very limited and contain known bugs (<a
href="http://bugzilla.ximian.com/show_bug.cgi?id=40689">
40689</a>). The class need to be re-designed.
* Support for adding/modifying OID using the
<code>machine.config</code> configuration file (algorithms
are done).
* RNGCryptoServiceProvider is currently only working on Linux.
The current implementation reside in Mono's runtime and use
the <code>/dev/[u]random</code> device (which do not exists
under Windows). A Windows specific alternative is available
using the Mono.Security.Win32 assembly.
* Keypair persistance for RSA and DSA. This persistance must
somehow be linked with X509 certificate stores (in planning).
* <code>PasswordDeriveBytes.CryptDeriveKey</code> is included
in MS BCL to provide compatibility with existing Windows
applications. The main problem is that the key derivation
algorithm can be different for every CSP (Crypto Service
Provider). However for compatibility we should provide an
implementation compatible with the MS CSP (most likely used).
* Analyse the current coverage of the unit tests on the
cryptographic classes and complete the unit tests.
* Optimizations (performance) on most class are possible. Some
have been done using the Community Edition of BoundChecker
(a free VisualStudio addon) - recommanded!
</ul>
**** Notes
<ul>
* All cryptographic algorithms are entirely managed, including
classes named <code>*CryptoServiceProvider</code>, with the
exception of <code>RNGCryptoServiceProvider</code> (which
resides in the runtime).
* Look at assembly Mono.Security.Win32 if you require more
compatiblity with the Microsoft implementation (like accessing
a particuliar keypair container inside a specific CSP).
</ul>
*** Namespace: <b>System.Security.Cryptography.X509Certificates</b>
**** Status
<ul>
* X.509 certificates are parsed using 100% managed code
(using the Mono.Security.ASN1 class).
* Software Publisher Certificates (SPC) used by Authenticode
(tm) to sign assemblies are supported (extraction from PE
files) but <b>not yet</b> validated.
* Unit tests are generated from a set of existing certificates
(about a dozen) each having different properties. Another
set of certificates (more than 300) are used for a more
complete test (but isn't part of the standard test suite for
size and time consideration, i.e. a 3.5Mb C# source file).
</ul>
**** TODO
<ul>
* Authenticode(tm) support is incomplete. We can extract the
certificates from PE files but cannot validate the signature
nor the certificate chain (and we're still missing some trust
anchors). See Tools section for more information.
* Integration with CryptoAPI (on Windows) isn't possible as
long as the <code>X509Certificate(IntPtr)</code> constructor
isn't completed.
</ul>
**** Notes
<ul>
* Except for their structure <b>there are no validation of the
certificates</b> done by this class (this is by design and
isn't a restriction of Mono!). This means that certificate
signatures and validity dates are <b>never</b> checked
(except when used for Authenticode, i.e.
<code>CreateFromSignedFile</code>).
* The newer X509Certificate class included in Microsoft's Web
Service Enhancement (WSE) is a little better (as it includes
CryptoAPI's validation) when <code>IsCurrent</code> is called.
See assembly <b>Microsoft.Web.Services</b> for more details.
* The class Mono.Security.X509.X509Certificate (in Mono.Security
assembly) is becoming a much better alternative - and will
continue to evolve to support the security tools.
* Microsoft implementation of <code>X509Certificate</code> is
done by using CryptoAPI (unmanaged code). From the exceptions
thrown Authenticode(tm) support is done via COM.
</ul>
<hr>
** Assembly: System.Security
*** Namespace: <b>System.Security.Cryptography.Xml</b>
This namespace implements the <a href="http://www.w3.org/TR/xmldsig-core/">
XML Digital Signature</a> specification from
<a href="http://www.w3.org/">W3C</a>.
**** Status
<ul>
* All classes are present but some (most Transforms) are only
stubbed.
* Most classes have their unit tests.
</ul>
**** TODO
<ul>
* All the transforms needs to be done. But this requires far
more XML knowledge than crypto. Note: Most tests runs because
the feeded XML is pre-c14n (by hand in the code) before
signing (not because the transforms works). In the short
term <code>libxml2</code> could be used to provide C14N, but
in the long term a fully managed class would be much better.
</ul>
<hr>
** Assembly: Mono.Security
<b>Rational</b>
This assembly provides the missing pieces to .NET security. On Windows
CryptoAPI is often used to provide much needed functionalities (like
some cryptographic algorithms, code signing, X.509 certificates).
*** Namespace: Mono.Security
<ul>
* Structures (ASN1, PKCS7) and primitives (PKCS1).
</ul>
*** Namespace: Mono.Security.Authenticode
<ul>
* Code signing and verification.
* Support for SPC files and PVK files.
</ul>
*** Namespace: Mono.Security.Cryptography
<ul>
* Additional algorithms: MD2, ARCFOUR (required for SSL)
* Convertion helpers
</ul>
*** Namespace: Mono.Security.X509
<ul>
* X.509 certificate building and decoding.
</ul>
*** Namespace: Mono.Security.X509.Extensions
<ul>
* X.509 extensions (from X.509, PKIX, Netsapce, Microsoft,
Entrust...).
</ul>
**** Status
<ul>
* Some part of the work has not yet been commited (cleaning up).
* A big part of this assembly is also included inside Mono's
corlib. The class are duplicated in this assembly so the
functionalities can be used without a dependency on Mono's
corlib (which depends on Mono's runtime).
* Unit test coverage isn't (yet) complete.
</ul>
<hr>
** Assembly: Mono.Security.Win32
<b>Rational</b>
This assembly goal is to provide maximum compatibility with CryptoAPI
to application running with Mono's runtime on the Windows operating
system.
<b>This assembly should NEVER be used directly by any application</b>.
The classes should only be used by modifying the <code>machine.config
</code> configuration file (and then only if this increased
compatibility is required by an application).
See the file <code>/mcs/class/Mono.Security.Win32/README</code> for
complete instructions.
*** Namespace: Mono.Security.Cryptography
**** Status
<ul>
* A RNGCryptoServiceProvider built on top of CryptoAPI. This
allows Windows users to get around the limitation of the
runtime RNG (which requires <code>/dev/[u]random/</code>).
* Wrapper classes for unmanaged versions of hash algorithms:
MD2, MD4, MD5 and SHA1 are supported. <b>note</b>: some
algorithms shouldn't be used in new design (MD4 is broken and
MD2 isn't considered safe). They are included to preserve
interoperability with older applications (e.g. some old, but
still valid, X.509 certificates use MD2).
</ul>
**** TODO
<ul>
* Wrapper classes for unmanaged versions of symmetric
encryption algorithms (like DES, TripleDES, RC2 and others
present in default CSP).
* Wrapper classes for unmanaged versions of asymmetric
algorithms (like DSA and RSA) which persist their keypair
into the specified CSP.
</ul>
**** Ideas
<ul>
* Similar assembly could be created for <a href="http://www.openssl.org">
OpenSSL</a>, NSS, crypto++, cryptlib ... for improved
performance and/or HSM support under Linux.
</ul>
<hr>
** Assembly: Microsoft.Web.Services
Microsoft Web Service Enhancement (WSE), known as Web Service
Development Kit (WSDK) in it's beta days, is an add-on the .NET
framework that implements WS-Security (and other WS-* specifications).
It also includes improved support for XML Signature (replacing and/or
extending <code>System.Security.Cryptography.Xml</code>) and X.509
certificates classes.
Note: WSE is distributed as an add-on because some specifications,
like WS-Security, aren't yet completed by
<a href="http://www.oasis-open.org/committees/wss/">OASIS</a> or
other committees.
<b>[*] There are some licensing issues to consider before stating to
implement WS-Security. All contributors must sign an agreement with
Microsoft before commiting anything related to WS-Security into CVS.
</b>
*** Namespace: Microsoft.Web.Services.Security [*]
*** Namespace: Microsoft.Web.Services.Timestamp [*]
**** Status
<ul>
* Nothing (yet) commited in CVS <b>[*]</b>.
</ul>
*** Namespace: Microsoft.Web.Services.Security.X509
**** Status
<ul>
* Nothing (yet) commited in CVS. However the classes in this
namespace are outside WS-Security scope. So development, for
those, could be done without signing any agreements.
</ul>
**** TODO
<ul>
* We need to define certificate stores (for both users and
machines). These sames stores must be linked with asymmetric
keypairs. This could also be used to store the SPC roots.
</ul>
<hr>
** Tools
There are many tools in the .NET framework that indirectly interacts
with some cryptographic classes. Mono will eventually need these tools.
Unless noted the tools should work on any CLR (tested with both Mono
and Microsoft).
**** Status
The following tools are complete:
<ul>
* <code>secutil</code> is a tool to extract certificates and
strongnames from assemblies in a format that can be easily
re-used in source code (C# or VB.NET syntax).
* <code>cert2spc</code> is a tool to transform multiple X.509
certificates and CRLs into a Software Publisher Certificate
(SPC) file - which is a long name for a simple PKCS#7 file.
* <code>makecert</code> to create X.509 test certificates that
can be used (once transformed in SPC) to sign assemblies.
</ul>
**** TODO
The following tools are still missing or incomplete:
<ul>
* <code>monosn</code> is a clone of the <code>sn</code> to manage
strongnames. This tools is part of the runtime (not the class
library) and as such is written in C and won't run without Mono.
* <code>signcode</code> and <code>chktrust</code> (in progress)
for signing and validating Authenticode(tm) signatures on
assemblies (or any PE file).
* Other tools like a, GUI-based, certificate manager...
</ul>
Note that many of the tools requires the class library and/or the
runtime to be ready for them. E.g. StrongName and Authenticode signatures
tools are of limited use until supported by the runtime.
<hr>
** Other stuff
<ul>
* SSL/TLS for secure communication (a prototype is under way).
Some work is already visible in Mono.Security assembly (e.g.
RC4).
</ul>
<hr>
** How to Help
Complete any of the TODO (and feel good about it ;-).
Add missing unit tests to classes or methods.
Write some documentation on the cryptographic classes for the
<a href="http://go-mono.com/tutorial/html/en/index.html">Mono
Handbook</a> as I'm not a very good writer (at least in English).
Optimization can also be done on algorithms as crypto is never fast
enough. Just be sure to test every optimization (using the unit test)
carefully - it's so fast to break an algorithm ;-).
Contact Sebastien Pouliot (<a href="mailto:spouliot@videotron.ca">home</a>
, <a href="mailto:spouliot@motus.com">work</a>) if you need additional
informations about the status of the cryptographic classes.
<hr>
Last reviewed: April 7, 2003 (post mono 0.23)
|