We will NOT call our application "webbank". We can of course compare it to webbank, and use the term when explaining.
Full-featured EpointSystem wallet clients:
- android
- m.epoint.org (only works from android !
- I installed zxing (from .apk, not from android market because to have QRcode displayed
- python
- commandline interface works (find it under vending_machine, see "python" below). Important, eg. for pre-paid-electricity and heat from producer-gas powerplants. (and pre-paid wifi of course)
- GUI client is highly desired (and should be easy)
- See below
- bash shell commandline interface is unlikely to be used by everyday users, mostly just programmers, for testing
Limited wallet client:
- Firepay, an easy to use wallet client.
- now partial withdrawal allowed, so firepay v0.4 can be used as a wallet (though only one-issuer, and no market connection yet)
- note that it does not implement gpg verification: only relies on ssl and trust the server
Some old-style epoint RANDs for your experiments/testing (note: these are intentionally the shortest allowed - 48 bit. Normally the secret RAND is not sent through any public or any unencrypted channel anyway):
- issuer: http://www.epointsystem.org/issuer
- no ept at this time. This is actually a live server, hosting convertible currency, 4 EPT = 0.004 EUR currently. You can also purchase internet wifi access in several places for this currency
- issuer: http://epoint.vems.hu/letsTest/ (on a test server. Try firepay, or PocketBook - see below). Please remove the ones that you redeemed, and put back one or more notes, with same total value (so others can also play with it).
- 10 ept: yIHN7eBI
- 9 ept: hJpSECiJ
- 8ept: NvHSyAIP
- 7 ept: 8Shdinwc
- 6 ept: 3n1KZm7W
- 5 ept:wiu6lo+t
- 4 ept:ir9U4mPlASLB+BAM
- 3 ept:Kb4yHhdb
- 2 ept: SBPRGN4z
- 1 ept: u+FrqsY5 PLEASE TAKE THIS FIRST WHEN EXPERIMENTING
During development, it makes sense to use several wallet clients (interoperability tests, and debugging), and historically that happened anyway:
RETIRED clients:
- EpointSystemMobileClient
- Pocketbook (JAVA Applet or Application, see below)
- old prototype. Not safe to use (might lose tokens)
- webserver webapp is NOT an option
- nem opcio egy webes felulet? NEM! Nem lehet biztosítani a bizonyíthatóságot ha nem a felhasználó gépe írja alá a tranzakciókat. A szerver nem tudná bizonyítani, hogy az utalást tényleg az account (pubkey titkos párjának) tulajdonosa írta alá
Quick-to-boot GUI client
We need something like python GUI client for Linux (and windows if someone likes to give up security completely), because android does not boot quickly on PC: currently android code is next to useless on PC for a wallet, although in future this might change (see android-x86.org or Myriad Group)
- python
- we do have a working command-line python epoint tool, namely https://www.epointsystem.org/trac/vending_machine/browser/pubterm/trunk/epoint-client/
- this can be the base of a python GUI wallet
- cd /svn/vending_machine/pubterm/trunk/epoint-client/
- python epoint.py
- apt-get install python-pycurl (if it misses the curl library)
- sending money is almost isomorph to sending files. After we get the python GUI working, looking at webkit browsers like midori (C) / arora (C++) again might make sense for a more secure C application that statically links with GPG instead of exec (exec-ing GPG is like saying "here is my secret data").
- PySoulSeek filesharing app (2003)
- Nicotine filesharing app (pysoulseek continued). Code is very easy to follow, so deposit / witdhraw or market transactions should be easy.
- python for bash scripters tutorial. Prefer subprocess.call() to os....() ? When calling gpg, prefer environment variable or stdin or file for any secret data, instead of command line arguments. (of course anything is allowed initially just to get things running)
- gist gnupg-python binding (apt-get install python-gnupginterface not enough ? ... "import gnupg ImportError: No module named gnupg" )
Basic functionality - overview
These simple functions are the building blocks of a publically auditable (which is the basic requirement to be non-fraudulent: any system that is not publically auditable will become fraudulent sooner or later. We have seen it in the "Modern Money Mechanics" MMM practice) clearing system.
Web-vault
- register
- anonymous registration allow receiving funds (and spending received funds), but to issue tokens, one must contact the LETS-manager to authorize the non-zero issuing limit.
- request payment (create new receiving account or using an existing account)
- internal function: safe logging (to prevent data-loss even if 1-2 hosts crash at the same time)
- transfer (make payment) within same issuer
- view history, reports, export data
The remaining operations might not be seen by the user, may happen behind the scenes (or even unnecessary, handled through market rules)
- exchange (DigitalMarket)
- exchange + transfer in one step ("transfer between issuers"). This is the most common operation (as the "bank transfer" is the most common operation with the government-masqueraded money).
- issue (if authorized). If one has issued N tokens, she can prove that her balance > -N (balance is greater than minus N). For any anonymous user that cannot issue tokens at all, N=0 so balance > 0 (balance is positive or zero: cannot be negative of course).
- unissue tokens ("destroy"). This decreases the issued amount. If one has excess tokens beyond the immediate spending intentions, and the issued tokens>0 at the same time, it's a good idea to unissue.
LETS-manager (or currency manager: similar functionality for market-connectivity currencies, and non-LETS type business currencies)
- authorize ("register") new LETS members
- manage issuing limits of members
- manage liquidity (via DigitalMarket)
How shall I call thee ? - nomenclature discussion
Balance might be better, but instead of Balance, the word VAULT (or wallet ?) has been recommended. (this page still uses "balance" here and there)
- Account: most people think of "accounts" as a "dropping-place", where it is possible to transfer to (loom.cc might have some good texts and images). Several accounts can be organized under buckets (or folders). A notable example: tokens that have been printed to paper, eg. QR-code (not to be accidentally spent electronically). Since EpointSystem allows one to have arbitrarily many accounts, the main entity could be called:
- Balance / VAULT / WALLET : a set of accounts one has access to (know the secret RAND).
- One can decide to have a destination account for each payer (customers)
- or one can create a new account every once in a while, every year, month or even for every transaction (with the non-PKI simple keys new account needed very frequently, since any tokens arriving to such account after the first spending are not sufficiently protected - the server knows the secret RAND. Noone would a to tell the a recipient directly as a payment - indirectly payment is appropriate ).
Basic goal: when someone types in a (valid, previously initialized) passphrase, she wants to be able to list and access EVERYTHING attached (without any further configuration, or file import). This includes key-signing (being on either side of the relation), authorizations, emits, history, actual vault buckets (folders ?) and actual balance, etc...
PocketBook (development version) - try now !
appletviewer http://epoint.vems.hu/letsTest/pocketbook.html
- appletviewer is somewhat better than browser, you see some more debug-output at least in this development version
- Please stick to one (or very few) passphrase. Withdraw all funds from it and put it back on top of this page before starting to use new passphrase.
- if you saved wallet with certain passphrase earlier ("k" was used for debugging, obviously not a good real passphrase), than enter passphrase to pw1, press OK
- if you just have some value in wallet (eg. deposited some epoints earlier), enter pw1=pw2 (repeat passphrase) and press OK to save to network storage.
- The network storage administrator will not be able to recover your wallet content (except if you give very short passphrase). Your wallet is encrypted (and decrypted) on the client. The encrypted file is stored under storageid=sha1(pw + "save") on the server: echo -n "mysecretpasswordsave" | sha1sum (except that actually uppercase is used)
- an intentionally short epoint: above (more than 1 epoint so you can split too: try not to lose all too early ;-) for http://www.epointsystem.org/issuer
- another issuer URL: http://epoint.vems.hu/letsTest
- try http://epoint.vems.hu/letsTest/info and http://epoint.vems.hu/letsTest/pubkey and http://epoint.vems.hu/letsTest/000454 (or any document SRL nr)
- download http://epoint.vems.hu/letsTest/pocketbook.jar
- this was made by cd /svn/epoint_wallet/trunk/j2se ; make pocketbook.jar, after barbecue-xxx.jar was added to CLASSPATH). Might also be built and run from eclipse of course.
- java -jar pocketbook.jar
img src="http://www.ideje.hu/download/epointsystem/epoint_eloadas/cc/410_pocketbook_application_snapshot1.png"
Access / Deposit the epoint code above. This only works if you added issuer http://www.epointsystem.org/issuer to the issuer list. If not, or someone has deposited earlier, than you see "invalid epoint"
Play with Withdraw / Deposit and see your balance change. You can use gpg to decrypt wallet file with the symm.key passphrase provided in pocketbook.
TODO: tutorial on print related functions
A recommended testing method: bounce some epoints back and forth between firepay and pocketbook. Withdraw from one, deposit in the other (called refill / top up in firepay), than the other way around.
Brainstorming
- Initially we also have a http://servername... that can provide most of the storage and gateway functions. But finally we do NOT want to rely on any one server. (but there is always the possibility to export data to a local file for one's ease of mind).
- As the passphrase is absolutely essential to reach a vault, finally we also want to provide some feature of storing the keys with suitable encryption and location possibly recovered by a certain number of trusted parties (eg. 1 notary + 2 friends). This is absolutely voluntary of course. But losing the key is certainly unrecoverable complete loss of the vault. It is not possible to access it (by design).
Architecture plans
- Latest achievement: PocketBook works as application (see above), but still hard to use.
- Printing epoints worked as well.
- Application can store the self-encrypted ePoints in local files (wallet and wallet.bak - try gpg -o wallet.plaintext < wallet ).
- theoretically also works as Applet, but you need to "withdraw" ALL epoints (print, writedown, store wherever you like) before closing the applet, the only way to carry on to a next session. This suggests more development. Read below.
- Applet can now save (encrypted) wallet to save.pl CGI on server. Saves to file (not SQL).
- 2009-12-20 Applet wallet => save.pl and retrieve seems to work. Of course more testing continues. (especially as special adversary/disaster models are added)
- Later (2010-xx) separate servlet (even separate virtual machine or separate physical host) will service vault and issuer. In final implementation : the applet must always connect to an onion gateway servlet. Onion gateway should have vault server directly (so quickest operation is possible, and default). Any other vault, or any issuer must be reachable via the onion cloud of course, possibly in multiple hops if the user desires.
- 2009-12-21 login (only pw1 entered) and save wallet (pw1 = pw2 entered) should be different dialog (or somehow more obvious to the user, eg. different "OK" button)
- 2009-12-22 besides the "Deposit", "Check epoint with chosen issuer" that is similar to current "Validate" function
- 2009-12-23 the method (order) of generating new RAND, split, than save new wallet file with the new RAND is bogus.
- We must first store any newly generated RAND in saved wallet (before using the RAND/MD. Even pooling a few, yet unused RANDs in our wallet, possibly of different lengths should not hurt).
- Than only use a RAND in split operation that is known (preferrably confirmed) to have been previously stored in a stored wallet. This prevents loss of epoints when save() fails.
- when showing the user any RAND, we preferrably want to show the (issuer-) confirmed value of it's MD next to it. This circumvents the case that think MD worths 100 while it's worth 1000: after we merged 100 to an MD that we believed to be 0 value, while in fact it had some (900 in the example) value.
- 2009-12-24 usability tests, and docs
- Issuer hot backup: transaction entries sent to a list of servers (either N-M on request or during operation). The backup issuer can verify and import sequentially.
- 2009-12-25 pocketbook detailed transaction log (which the mobilewallet already maintains)
- 2009-12-31 verify that when checking multiple issuers for certain MD, we check the MD, not the RAND ! (should be that way already)
- 2010-01-05 Recommendations: how to name folder where we store printed ePoints, to prevent accidental doublespending or losing epoints
- 2010-01-20 Document basic backup, and data maintenance mechanisms. Eg. migration to new balance (new passphrase)
- 2010-03-10 Applet should also be able to store self-encrypted ePoints in DHT (through the server gateway). Server MUST also store in SQL DB of course.
- ?? ?? ?? Client also stores double Reed-Solomon "FEC" code in DHT to provide erasure protection. Similar as the redundant coding used on CD.
- Should we use dynamic size, or fixed size arrays ? CD uses 12x12 blocks AFAIK.
- Client can recover DHT erasure errors using the Reed-Solomon decoding. (creeping featurism)
- Issuer migration: move the private key to a hot backup (after transaction data is already there). Advertise new URL in keyserver if necessary (new URL in UID note).
- Client migration: in case of prolonged access problems, clients should query keyserver to find out new URL.
- Make it possible to have fully operation back in 5 minutes in case of raided servers, or even DNS attack (one of the worst, centralized-feudalistic part in internet architecture)
- 2010-07-10 DHT should be reached (through the webserver as gateway) via onion routing (read Tor.eff.org and mixminion remailer network, some similar mechanism) if so configured. In this case the gateway MAY NOT be able to store in its own SQL DB (it cannot read onion envelopes). Any operation can work fine without trusting the gateway, we retreive from DHT. Gateway can provide backup services to store another copy of the self-encrypted data (with fast retrieval) of course.
- If we want complete security, we must verify we are running the proper application or applet (or Firefox plugin). With the above precautions, candy-trojans are likely the most feasible attack for Joe Smith.
Operations
See balance
Transfer
See history
Add account to balance (existing account, or create new one)
Configure backup server and public key. One can retreive virtually all information from the backup server, and decrypt with relevant secret key.
- connected accounts
- history / detailed transaction log
The backup contains very similar data as the web-balance primary datastore. However,
- web-balance MUST know secret+public key for the primary datastore to access data, but only public key for the backup.
- Also, the backup MAY be Write-Only-Memory (even posting messages to an email address is possible), without possibility to delete old files.
Development notes
- starting stone makefile
- Wallet.java used from swing/PocketBook.java
- Yes, it works, but it has a very counter-intuitive UI. It was basically a proof-of-concept and it utterly failed the usability tests. It is 4 years old now. The j2se branch is for web-based and desktop stuff.
- I should be able to get it work with current epoint_issuer ? or the document templates have changed since than ? It should work, I think.
- It runs either as an applet and an application. As an applet it stores ePoints only in RAM. Thus, it needs to be emptied after use.
- If run as an application (java -jar pocketbook.jar) it saves everything in a file called wallet (a pgp-encrypted xml file).
- Or if you don't give a password, then it is plain xml.
- The mobile wallet uses stuff from j2me.
- actually, the mobile wallet has the model, view and controller so well separated that it might be a better codebase to start with. You just need to replace the j2me views with swing views. The model is also a bit j2me dependent, because it uses the recordstore, but it can be factored out. I am not certain which is the easiest way forward.
See EpointSystemStorageNetwork for info on how the server side of DHT background storage and onion to reach multiple issuers can be implemented.
Pocketbook symm-encrypts data in this PGP format ( gpg --list-pac ):
:symkey enc packet: version 4, cipher 2, s2k 1, hash 2
salt 880f8ba20bff08e8
gpg: 3DES encrypted data
:encrypted data packet:
length: 1880
mdc_method: 2
gpg: encrypted with 1 passphrase
:compressed packet: algo=2
:literal data packet:
mode b (62), created 1261051641, name="_CONSOLE",
raw data: 2952 bytes
gpg -c --cipher-algo 3DES --s2k-mode 1 --s2k-cipher-algo 3DES --compress-algo ZLIB </tmp/F.1 > $F
produces very similar, gpg --list-pac $F shows:
:symkey enc packet: version 4, cipher 2, s2k 1, hash 2
salt 35df9038e6156322
gpg: 3DES encrypted data
:encrypted data packet:
length: unknown
gpg: encrypted with 1 passphrase
:compressed packet: algo=2
:literal data packet:
mode b (62), created 1261052713, name="",
raw data: unknown length
gpg: WARNING: message was not integrity protected
