Ricardo is very secure! Ricardo is the only system that espouses an top-to-bottom 7 layers model of system security. In fact, the 7 layer model was discovered as a result of building Ricardo.
In terms of practical, economic terms, the threats to any user of Ricardo are all "outside" of Ricardo's control: viruses on the user's PC, etc. See the User Security section below.
The encryption layer of SOX uses the triple-DES secret key cipher to encrypt each secured packet. SOX uses the full 3 keys giving 168 bits of effective security.
In order to establish the secret key for the triple-DES cipher, the client initiates a key exchange using the Diffie-Hellman key exchange protocol. This is secured by encrypting to the server's public key.
Man-in-the-middle attacks are prevented by encrypting the key exchange to the issuance server's key. This in turn is signed by the Server Operator's certification public key which itself is distributed within the Ricardian Contract for the given instrument.
Each Ricardian Contract is signed by the Issuer's public key, thus ensuring that the contained Operator key cannot be tampered with.
The public key algorithms used include both RSA and DSA. Strengths generally range from 1024 bits to 4096 bits.
Unlike other protocols, the above means that the initial, primary Issuer key comes from a trusted and verifiable source: the Ricardian Contract itself. The Ricardian contract is verifiable in these ways:
It is securely identified by a message digest, which can be verified manually, just like an OpenPGP key.
Every time you receive a payment or send a payment in the given Ricardian unit, you will by definition prove that you have the same unit as your counterparty.
The Issuer's key within the contract can lead you via a web of trust to statements from other people that you already trust.
Thus, SOX can deliver end-to-end security of the chain of certificates, something that is not achieved by conventional certificate authority based solutions.
Once an encrypted channel is created, each request delivered over the channel to the SOX Server is signed by the private key of the user's key pair.
A public and private key pair is the user's handle on persistent identity. This is often called a pseudonymous identity or a nym for short, because it does not relate to any other identity that a user might have.
Each nym is a public key pair using the DSA public key algorithm. The client software selects the strength, which is generally 1024 bits and above.
All systems face threats. The collection of threats that face a system is called the Threat Model. Once determined, the designers of the system create the Security Model to address these threats. That Security model then is applied to all aspects of the system.
Threats to Ricardo and its users fall into these approximate groups:
external threats to the server,
internal threats to the digital value and any reserves, and
threats to the User.
External threats to the server, and internal threats, are both the responsibility of the Issuer.
WebFunds protects the User to the extent that it can. Unfortunately, unless the Issuer also sells and dictates the entire platform of the User, there is little the Issuer can do to eliminate User threats. User Security below for threats to the User.
The Issuer uses the techniques of Governance to secure the system from insider attacks.
The Issuer would be expected to contract to an Operator who would provide a secure environment. The Issuance server software runs on Unix, and this can generally be secured with some effort by careful configuration and firewalling.
As the Issuance Server is expected to handle large amounts of value, the requirement for system security is uncompromising. For this reason, servers are generally more expensive than webservers. For example; the only thing that should be on the server is the Issuance Server software.
The financial system itself -- the network of issuance, retail and trading -- is protected by a comprehensive range of system security measures, governance practices and riskless design principles. These are addressed in the Security White Paper.
SOX's threat model is listed as requirements in Development of an Open and Flexible Payment System. In that paper, each requirement is addressed and met.
This depends primarily on the User and the Application they are using to access the system. In the case of WebFunds, there is a backups facility to assist in preventing lost keys.
In the defence of theft, Users need to guard their PC and software from threats. Users using WebFunds should make sure that their PCs are protected from emailed viruses, hacking attempts and the like. Ideally, for high security situations, the platform should be a PDAs or similar trusted device with only the one application installed.
See your website for more details.
In general, never click on a link that takes you to a secure site unless you trust where the link came from. As a good habit, type in the link yourself.
The biggest threat to your passphrase is that an attacker will mail you a page asking you to log in. This is called "spoofing" because they imitate, or spoof, the original website.
But instead of providing the original website, it is simply a tool to collect your passphrase and other details. So, avoid clicking on a link mailed to you. If it is an important link, you should be able to type it in manually from memory.
This is an unfortunate shortfall in the security of modern browsers and email clients.
If the account can be identified, the Issuer may have the power to invoke lost account procedures. These will almost always be expensive, as substantial administrative actions need to be taken in order to unravel assets within the system. That expense will be borne primarily by the user.
If the key is stolen but not used, then the case may be similar to a case of loss of data, above.
If the key was used and the assets were moved then the case gets rapidly more expensive and the possibilities of recovery diminish towards nothing. Ricardo does not cover the case where a private key or passphrase was stolen from the user.
It may be possible to track assets as they are moved, but this involves many different administrative centres. That is, if the assets are sold to an exchange provider, then the full cooperation of that entity is needed.
The end result with stolen assets in some cases may well be that the assets are traced to the thief, but it may be too late to re-acquire them. As Ricardo is a traceable (nymous) system, stolen assets can be eventually tracked down within the system. As the assets go out of the system - that is, they are bought and sold for other value - then everything depends on where they went next.
Tracking is very expensive, and it is only used in the case where the system itself is threatened, by, for example, a major software failure or an extortion threat against controlling parties. The traceability of payments between SOX accounts is a designed defence against what is known as The Bank Robbery Problem.
In this problem, the Issuer is forced ("at gunpoint") to release some critical asset such as the manager's account or the Mint account. Money is then created and spent by the attacker. The attack doesn't work, because the payments made can be readily identified at the source, and then traced. Depending on the severity of the attack, payments can be limited or slowed or even switched off.