Despite the fact that cryptocurrency transfers are probably the safest way to transfer value, there are still serious security considerations about initiating the transfer itself. The wallet address is long and hard to remember, which opens the doors for hackers to spoof it. There are viruses whose sole task is to watch the clipboard for wallet addresses which they would replace with the hacker’s address, so you copy one thing but paste another. Attacks on the user’s network allow hackers to intercept wallet addresses and replace them “on the fly”. Compromised emails and social media accounts are probably the biggest contributors to wallet spoofing. To solve these problems and secure our transactions we issue X.509 certificates, where the user identifying information is tied to the wallet’s information, so its always easy to verify the recipient’s identity.
In order to issue a certificate the platform verifies the user’s identity and then asks to perform a small transfer for wallet verification and confirmation that the user has access to the wallet’s private key.
The issued certificate is then signed by the certificate authority (CA) which performed the initial user’s data verifications. The CA’s certificate and the user’s certificate are now linked into a certificate chain.
X.509 certificates cannot be modified without breaking the certificate chain validation, so it’s safe to share them even over a compromised network. Moreover, Propy will publish the open API for certificate issuance and validation, so this functionality can be used not only via our platform, but can also be integrated for automating verifications in any wallet. Here is an example of a certificate with an embedded BTC wallet address:
In order to validate a certificate the system performs many checks as described in the CA-Browser Forum Baseline Requirements, where one of the most important verifications is the certificate chain validation.
When the certificate authority signs the user certificate, it calculates the hash of the certificate and encrypts it with it’s own private key. Then anyone can validate the signature by taking CA’s public key (publicly available), decrypting the hash and comparing it to the hash of the certificate.
For additional security we have added one more link in the certificate chain — the Root Certificate Authority which signs the intermediary CA, so the validator will obtain the user certificate, validate the signature of the signer (intermediary CA) and in case of success then validate the intermediary itself against its signer — the Root CA. Exposing the Root CA to the internet is dangerous, so it is stored on the offline hardware security module (HSM).
Certificate Chain Security
While designing security systems it’s important to assume that any part of the system can be compromised and build countermeasures to eliminate the compromised part. Let’s assume that one of the Intermediaries suffered a breach and there was a leak of the private key; in such cases the perpetrator will be able to issue fake user certificates and try to substitute the real ones. To prevent this we have built additional security steps into the verification service which will reveal fake certificates and automatically issue a revocation for the affected Intermediary, rendering all the certificates issued by this CA invalid. The affected CA node will be terminated, a new node with a newly issued Intermediary will be created and the certificates for legitimate users will be recreated automatically.
The Propy smart contracts are equipped with the capability to automate an escrow functionality, where for each deal a unique escrow wallet would be automatically created on a read-only node, controlled only by the Propy smart contracts. But despite the fact that nobody can access the node we need to assume that it’s possible to breach such a node and to provide an additional level of protection — a multi-signature wallet. Multisig wallets require M-of-N signatures in order to initiate the transaction. The multisig wallet is created using the buyer’s, seller’s and escrow’s wallets while two out of 3 signatures will be required to initiate the transfer from such a wallet. When the deal has succeeded, the smart contract will signal the Escrow node to release the funds to the seller, then both the Seller and Escrow nodes have to sign the transaction. In case the deal is canceled and the money have to be returned to the Buyer, both the Escrow and Buyer nodes will need to sign the transaction.
A combination of X.509 certificates and multi-signature immutable Escrow nodes significantly raises the security of crypto transfers, which is especially important for real-estate deals given the large amounts of funds being transferred.