|
|
|
Emoney protectionProtection of deposits of electronic money
|
|
|
|
|
|
Here are some great security features for a website which deals with electronic money transfer system (EMTS):
The main problem of any EMTS is not the log-in process. There is always the possibility for the user's computer to have a malicious program on it, which monitors when the user logs-in the EMT. No matter what the log-in process involves, the malicious program could access the user's account during the time the user is logged. At this time, companies who have large amounts of money stored in an EMTS must split their money in several accounts, and still fear the possibility of an account to be emptied at any time, either by outsiders or insiders. So, we must consider the security of the user's side to be inexistent. But, even in such a case, there is still possible to protect the money from an account from being transferred without the owner's knowledge. This can be achieved with action-driven authentication and with vaulting.
Action-driven authenticationAn action-driven authentication system (ADAS) is a system where certain types of actions (like spends) must be authenticated every time they are performed. Users should have the ability to activate the ADAS for their accounts when they want, but must not be able to deactivate it later (or at least be able to deactivate it only by using a form which is digitally signed with their asymmetric key which is already loaded in their account). This ensures that nobody can ever deactivate the ADAS for a specific account. To activate the ADAS, the users must load, in their accounts, their public key for asymmetric encryption. Once loaded, the key can be changed only by using the ADAS (but can never be deleted). The ADAS doesn't replace the login process. It could be used for login too, but that's not its main goal. There are two methods to implement the ADAS: one software, one hardware. In both cases, the software layer requires to implement a system of commands which can be created (digitally signed and encrypted) on a computer which is not connected to the Internet, and then transferred to a computer which is logged to the EMTS, and send them to the EMTS.
Hardware implementation This requires a hardware token independent from the computer, but which connects to the computer, which communicates with the EMTS through the browser and reads / writes data (about each transaction) that is asymmetrically encrypted (by the token, not by the computer). A display and a button are necessary (on the token) so that the user may accept (or not) a certain transaction. Certain information about each transaction is displayed to the user.
VaultingA user can use the vaulting feature to lock a specified amount of money for an indefinite time. This means that, after the money has been locked, the user has no possibility to transfer that money to another account, or to unlock the money, except for the specified cases. This vaulting method is called "delayed actions vaulting". To activate the vaulting, the user has to specify the period of time (CEPT – Command Execution Period of Time), in days, between the creation and execution of a vault command. Its minimum value is 2 weeks. Money can be put in the vault of an account at any time, in any amount; the user can perform only delayed actions with the money from the vault. The non-vault area of the account is called cashier; the user can immediately perform all actions with the money from the cashier. The user can interact with the vault only by using commands. Users should periodically check their account to see if there are changes to it made by other people, with a frequency smaller with at least one week than the CEPT. For example, if a user sets the CEPT to 5 weeks, it should check its account every 4 weeks. If this periodical check is not done, and if someone else has access to the account, that someone could change the password of the account (to lock out the real owner) and setup unlock commands and just wait for them to be executed. Therefore, the real owner of the account should have the time to initiate the proper procedures to take over his account, by filing a complaint to the EMTS to investigate the issue. Even if the user name and password (required to access the account) would be public, the only thing anyone could do would be to change the password of the account (or other parameters), but not spend the locked money. It is essential for the owner of that account to have a way to unlock the money (and change the user name and the password). See premature termination. Each account has a parameter (AVT – Automatic Vault Transfer) which indicates that any amount of money (equal with at least AVT) received from another account is automatically put in the vault.
Individually locked deposits There is an alternative method for the delayed actions vaulting, method called "individually locked deposits vaulting" (also called "term-storage"). In this case, the user creates individually locked deposits with a specified amount of money, which are automatically unlocked at a time specified when the deposit was created. However, this method has some security weakness not present in the delayed actions vaulting. What happens when the locked deposit expires and the money is unlocked? Obviously, it becomes possible to spend it. The owner of the account could create a new locked deposit, but there is still a time when the money is unlocked. To fix this issue, the expiration date of a deposit could be extended before the money is unlocked. But here is the problem. If someone else than the owner of an account has access to the account, he is not able to spend the locked money but he could extend the expiration dates of all deposits for maximum possible. This would mean the owner of the account would no longer have access to the money until the deposits expire. However, this can be fixed by allowing only short life times for locked, maximum a few weeks. The problem in this case is that the user must always be alert to lock the money often. Here is another problem. Say you lock some money for a day. Now say a thief has your password. He can change it (and so lock you out of your account) and then wait for the money to be unlocked. So, he gets your money. It's possible to fix this, somewhat, by disallowing a password change if there is any money in the vault. The best solution is to have the ability to lock all the money from an account until a given date, with no possibility to extend the expiration date. This solution could be used only for when the user has to leave the account unsupervised for long periods of time. To actually do the locking, the user would have to use a delayed command, just like one for the vault.
CommandsThe system accepts various commands which affect the vault. Each command has its own execution time. Once a command is created, its execution time is set with the specified time (which must be equal with at least the creation time of the command plus CEPT). When the EMTS time is equal with at least the execution time, the command is executed. Commands:
Once a command is created, it can be deleted, but it can not be modified. After a command is executed, it is deleted from the command queue.
Weakness Although the user can periodically verify the active commands, it's still possible to make him believe he is safe. It's possible that the computer used to connect to the EMTS has malicious programs on it, programs which interfere in real-time and display a list of active commands different than the real one; this could be done by simply intercepting the HTML page displayed to the user, and removing from it the commands of the thief (and then displaying it to the user). This way, the user would not be able to see if there is any active command which he didn't set. Therefore, it is necessary to also have a digitally signed list, which the user could check on another, secure, computer. However, there is a simpler method (but not as secure). The list of commands can be put in an image. The background of the image would contain some text (two words) and would work just like a Touring number. To verify the authenticity of the list, the user would type the first word in a form and send it to the EMTS; he must also remember the second word. Then, the EMTS would respond with the second word. If this word would be the same as the one he remembers, it safe enough to assume the list of commands is authentic.
Vaulting Q & AAgain, why is the delayed actions method better? While the money is in the vault, it's not possible to spend it anywhere. If the user has money in the vault then in order to spend it or get it out the user has to create a command for such an action. But this command is not executed when the user creates it, but only two weeks later. The thief would have to do the same thing in order to get money out of the account. Even if the money is supposed to be transferred to the vault of the destination account, he still has to wait two weeks after he initiated the transfer. If the user checks every week what commands are pending for his / her vault (for spends or unlocking), he / she can see if a thief has created such a command (and simply delete it). Since the thief's command is also executed only two weeks after he creates it, and the user checks the pending commands every week, if he / she no longer has access to his / her account he / she has one week left to take action to determine the money issuer to at least freeze the account until the matter is settled. Also, the thief can't lock the money for a long time (because the money is already locked). But the main advantage is the time that the user has to take action. Basically, the delayed actions method is the mirror of the individually locked deposits method. In the case of individually locked deposits the user takes action to lock the money, whereas in the case of delayed actions the user takes action to unlock the money.
User identificationThis feature is not necessary for vaulting, but may be needed in case of a premature termination, to identify the owner of an account. This feature would make it significantly easier for the account owner to identify himself, either to the EMTS or in a court of law. Every account has 10 slots which can be uploaded with a picture of the account owner. Once an upload is made, it is not possible to delete / replace the picture from that slot. More than one slot is necessary because each person changes in time, and the owner may need to update the picture. The picture uploaded by the user is used only offline if the user needs to prove his identity, in case he wants to unlock all the money from the vault before its normal expiry date. If a user decides to use this form of identification, it is essential for him to upload only his picture, and nobody else's. Otherwise, he could have problems trying to identify himself as being the account owner. Note: companies may have problems with this form of identification, since only people can upload pictures.
Premature terminationIf absolutely necessary, there must be a way to prematurely unlock all the money from the vault. This means that the money from the vault would be unlocked. A user could request at any time a premature unlocking of all the money from his vault, using a digitally signed form. This form is then processed by the EMTS and a confirmation is sent to the user. Now, the user has to obtain a court order to identify himself as the owner of the account. The EMTS requires the user to be the one who resembles with the pictures from the account for which the request for premature termination is. When identified as owner of the account, the person would be allowed to change the user name and password of the account, and have the money he needs unlocked. Users could be allowed (without a court order, for a fee) to change the user name and password of an account (for which they have either the user name or password used at some previous time, but not older than one year), but not unlock money from the vault. This way, if the user requesting the changes is not the real owner of the account, the real owner would be unable to login into his account and would thus the necessary steps to freeze the account until the ownership is solved.
One-time passwordsOne-time passwords can be used to defeat malicious programs which interfere with spends when the user (= tourist) makes them using an insecure computer, and offer great security for no cost. Each account has an option which tells to the EMTS whether to ask the user to confirm spends with one-time passwords, when he logs-in with limited access. The full access can't be protected this way because it can be used to reset the one-time passwords list.
How it works The user logs in his account (with full access) and uses a function named "Generate one-time passwords". The EMTS generates a table of random passwords: 10 rows * 2 columns. The passwords from each row are associated, but there is no mathematical relation between them (= they are purely random); the passwords from the first column must be unique (= there must no duplicate among them). Here is an example: The table is put in an image file and downloaded on the users computer. From this moment, these passwords are activate and the EMTS accepts any of them, anytime, to authenticate transactions. If the user generates a new set of passwords, the old set is deleted; basically, only the current set of passwords is active. Each password has up to 10 characters (letters and digits). The user prints this image and puts it in his wallet. Then he deletes the file from his computer. He goes to any computer and logs in his account with limited access. When the user wants to make a spend, he chooses the destination account and amount of money to be paid to that account. Then he clicks the spend button. So far, this is the normal spend process. The EMTS responds with an image, which is displayed to the user. This image contains the following information: the destination account, the amount of money to be paid, the password from the first column of any of the rows of the active one-time passwords table. The information from this image is displayed like a Turing number, and overlapped in a way that makes it impossible for a malicious program to extract the password from the image, in less than 5 minutes. The user looks at the response image and reads the destination account and amount of money to be paid, which he typed, and the password. If the information he typed is correct, and he finds the password in his passwords table, he then sends to the EMTS the password from the second column of the same row as the password from the image. At this point, the EMTS knows the user wants to make that transaction. If the EMTS doesn't receive the response password in less than 5 minutes, the transaction is canceled (and the password marked as used). Once a row of passwords is used, the EMTS marks it to know not to use it again (in the same set of passwords). The system only needs to know the current set of passwords; it doesn't need to store old sets of passwords. After all passwords from the current set are used, the EMTS could send an (encrypted) email to the user, with a new set of passwords. This way, the user doesn't need to log in his account to request a new set of passwords (if he needs more). If the user retrieves the picture with passwords on one computer, and logs in the EMTS using another computer, no malicious program can have both the user name and one-time password to access the user's account. This way, a tourist can have safe access to more than one table with passwords.
Example The user logs-in and makes a spend request to the destination account (nobody@nowhere.none) and with the amount to be paid (1.5 GAU). The EMTS responds with the picture: The user recognizes the destination account, the amount to be paid, and the password (381645). The user responds with the associated password (276481). The EMTS makes the transaction and marks that row of passwords not to be used again.
Weakness If a malicious program could extract the password from the response image, then it could replace the information the user initially sent to the EMTS, and then replace the image with which the EMTS responds (because this image would contain the correct password, but a different destination account), with an image it generates with the extracted password and the information the user typed. There is a way to protect against this, but it would be too complicated for normal usage. The protection could by done with another column of random passwords which would be combined with the destination account, using a function like adding two numbers (or even characters). |
|
|
|
|
|
|
|
|
