|
|
Developers
|
|
||
|
|
Vela is a set of open source applications developed in C#, which work on any system with DotNet (at least version 4.0). Vela doesn't work on Mono because this doesn't support WPF. Vela is designed to handle the work required to implement an action processing service compatible with Vela. Of course, service providers still need to develop the code which processes Vela documents inside their system, but that is all they need to do. Vela works only with the little-endian data format. The Vela libraries can be used separately. The source code is open source and heavily documented, but given the nature of applied cryptography, you should try to understand the inner workings only if you have significant cryptographic experience. For examples, see the source code of "Vela.Tester", from which you can understand the core functionality. The serializer and deserializer are custom made, using reflection. This guarantees the same serialization output, regardless of the platform it runs on, which is critical for signatures. The generated pseudo-random numbers pass the DieHard batteries of tests. Use the "Work \ Generate entropy file" menu, from "Vela.Tester", to generate a test file.
Protection against attacksProcessing asymmetrically signed and encrypted documents is a very slow operation. This fact exposes an Vela service provider to potential attacks where someone would try to suffocate the service with many requests for document processing. Using an automated process, an attacker could succeed to effectively shut down the service provider's ability to process the documents of legitimate users. A network traffic filter integrated in Vela mitigates such an attack.
OrganizationsThe following features are part of the framework but are not exposed by "Vela.Im". Organizations may get significant benefits from using group identities. A group identity simply groups the identities of several people who work for the same organization. A group identity allows a service provider to require that in order to execute an action in a service account, all the members of the organization (or a minimum number of members) must sign the request for the execution of the action. For example, an organization might have an account with a payment service where it keeps (some of) its money. The organization would not want any single member to have full access to this account, but rather request that the payment service executes only payments which are signed by 3 (out of 5) members of the organization. Vela can make this happen. A group identity also allows a user of Vela to encrypt a document for the organization. It is possible to encrypt the document so that each member of the organization could decrypt the document independently, or it's possible to require (with cryptographic strength) that all members of the group be present in order to decrypt the document. Even further, it's possible to encrypt a document in a way which requires that most members of the group be present in order to decrypt the document, but some members could miss. Moreover, it doesn't matter who is present and who misses from the decryption process. All that matters is that the minimum number of members is met. For example, if the board of directories of the organization has 5 people, but only 3 of them are required to decrypt documents sent to the organization, the Vela framework can make this happen.
PerformanceHere is a complete log of the tester application, "Vela.Tester". All tests have been performed with the GUI edition of the "Vela.Tester" on a computer with a 1.73 GHz Intel Mobile Core i7 processor, with the storehouse on a software encrypted SSD, on Windows 8 64 bits. Legend:
The payment service endurance test, with one tester application instance, has achieved 0.29 seconds per operation after 6'500 operations. This test includes local round-trip processing (= client and service), with local network communication; the data is encrypted and signed in all relevant ways.
Testing the serviceYou can test the payment service which is part of Vela. This service was designed to be as scalable as the underlying storehouse engine. All the operations required in a payment application, both client and service sides, are being performed. The payment service test is a very harsh one when multiple instances of the tester are used. All the instances compete for the same service resources (= same two accounts). Since, also, the client and the service both take processing time from the computer, this test is significantly slower than a real-life payment service application. If you run too many instances, there will be storehouse timeouts. You should not run more instances than the number of (physical) cores that your processor has. Here is what you have to do in order to test the service:
If you want the service to perform a lot of operations, you have to increase the "FirewallKnownPeerProcessableSizeMax" value from the service's configuration file. The default value is sufficient for a few thousands of operations.
DeadlocksThe tester (and Vela itself) will show deadlocks from time to time, but it's the kind of deadlock which occurs when two transactions try to convert an intent exclusive lock to a full exclusive lock for the same resource, or convert a row lock to a page / table lock, that is, it's a consequence of the design of the locking system. These deadlocks are different than the deadlocks which may occur between two threads where the locking system is far simpler. SQL Service Compact Edition reports only timeouts, but SQL Service Full Edition reports deadlocks. In order to see what is happening, create a log file by changing the configuration file of the service as follows:
The logging mechanism uses a global mutex for thread-safety, and all trace messages are synchronously written in the log file, so there can be no missing trace message.
ToolsEnvironments: VisualStudio, SharpDevelop, XamarinStudio (has issues recognizing some Vela projects). |
|
||
|
|
|
|