Topic: [ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase. - page 5. (Read 19448 times)

Sounds great. Will be following your project closely. Let me know when the "Shake Down" phase begins... bitcoins or not I would love to test your security.

Watching... awaiting the URL!

Openpay is just what Bitcoin needs

So I could just use ANY of my credit cards (Master, VISA,..) and do not need to have heard of bitcoin before in order to use it right?
So ANYONE with a credit card could just go up to a merchant that uses your network instead of the traditional bank ones and without even knowing pay with his/her credit card?

Pls correct where wrong, thx

In regards to translations, Bitcoin itself uses Transifex.com (https://www.transifex.com/projects/p/bitcoin/resource/tx/). Looks like a good platform, and it's free for open-source projects.

@Isis

Hey. As a non techie it all sounds very interesting even allowing for my limited brain capacity. The sort of thing that you know needs to come along in order for Bitcoin to evolve but have to wait patiently for the clever people to come up with.

Re: the insurance. How does that work? Does the network take a fee as an insurance premium?

Also, if this or a similar project acts as a gateway to a wider audience for Bitcoin it would be a good opportunity for those involved to get together and work on a better visual identity that projects a more suitable image of the technology than that damn coin.

RE: languages
The crowdin.net framework that is used in MultiBit is very easy to use and set up. For open source projects it is free. Recommended. I can certainly mention it to the MultiBit translators but it very much depends on their overall interest in the project as to how much time they have free.
The secret with internationalisation is to start with property files for UI elements right from day one as it is a (very boring) task to retrofit it afterwards.

For open source projects I think there is a limit as to what can realistically be translated (due to manpower and money constraints). For MultiBit I just concentrate on the UI being localised - the help and documentation is all in english and, realistically, I would expect that to be the case for the immediate future. As all the translators time is donated, to localise 400 phrases is 'doable' but no-one will translate a 10,000 word document for nothing.

RE: website
The MultiBit website is pretty much all static HTML and thus pretty easy to copy and change. If you want a more dynamic website it would not be a very good starting point - it is basically handcraft HTML and CSS. I am not sure I would want to do the upkeep of the whole of *another* project website but would be happy to contribute to get it started. Do you have a domain and somewhere to host it ? I can certainly 'clone' the multibit.org website and then we can start reworking it.

RE: integration of enrollment and self issurers.  I think there is potential there definitely.  MultiBit is aimed for new bitcoin users so it might end up better to fork the code and rebrand it as something OpenPay. MultiBit is all opensource (MIT licence). We can see how that pans out - it primarily depends on what user storys you have to implement. Certainly using/ reusing the maven build and the installer work would save you a lot of time.

You might also want to start up a Twitter feed for your project as that is quite a good way to keep everyone informed on progress.

As I understand it, soft marketing ("presence") is fairly important for this project as you want to have enough of a critical mass that retailers and equipment manufacturers want to include OpenPay functionality by default on their smart card readers.

Thanks for the offer!

There are a few things.

First off the documentation as it comes along will be written in english, but will need to be cleaned up and translated.  I noticed MultiBit is available in various languages, if you have translators that would like to help with the translation effort that would be great.
Second, your website is clean and looks really good.  Would you mind seeing what you could do for the Open Payment Alliance website?

Thirdly, we've been talking about an app for self issuers (people who want to self bank) and retailers such as check cashers & money changers (retail bankers) who may wish to issue & enroll their customers onto the network.
MultiBit looks like it might be a good place to implement that type of functionality.  OpenPay transactions shouldn't be too difficult to integrate into multibit.  We should explore that path once the reference implementation is complete.

Let me know what I can do to help.
With MultiBit being written in Java there is an obvious synergy between the two projects.

I just love the idea of bridging together the EMV network and the bitcoin network.

EMV issuance requires a formal acceptance process and a formal organization.  That will be the purpose of the Open Payment Alliance to advocate and move that process along.
The Open Payment Alliance will benefit from the credibility of it's member base.  As the member base grows so too will the momentum behind it.
Technically it's no problem, but administratively it's a bit of a nightmare.  My guess is they will both go live about the same time though.

That's good, the reference implementation is built on top of bitcoinj.

I've already documented quite a bit of the technical details in another thread on this forum, but I'll explain how it works here in a shorter summary.

There are 2 basic versions of OpenPay, these are EMV (chip & pin or NFC) and magstripe.

EMV is by far the easiest from a technical standpoint, we load a transaction signing applet onto the card along with a a standard bitcoin keypair with the private key encrypted with a strong encryption such as AES.  (Card here can also be any NFC device that is EMV compatible such as your cellphone)
The POS terminal queries the card and asks for a list of public keys (bitcoin addresses) that the card can sign for and hands this list off along with the amount of the transaction to the merchant gateway service.  The gateway service queries an exchange (assuming the merchant wants local instead of BTC) to convert the transaction amount from local currency to BTC.  Next the gateway queries a balance service which returns a list of unspent txouts for the addresses stored on the card.  The gateway then assembles the transaction and hands it to the card for signing.  The card tells the PIN terminal to prompt for a pin, this PIN is used as an oncard decryption key for the private portion of the key.  Assuming the key decrypts properly then the card signs the transaction and sends it back to the pos terminal/gateway.  This is now a standard BTC transaction that can be sent off to the network.  Since the gateway is the one crafting the transaction there is no need to wait 10 minutes for verification.
If the merchant is configured for clearing in local currency then after the network verifies the transaction then their service provider will execute a BTC sell to convert the BTC into the merchants local currency.  This could happen periodically say once a day, or really whatever the merchant and service provider agree to.

That was EMV, it's very straightforward, simple and direct.  All we need is to get an IIN for OpenPay from ISO and we can get that service operational in a few weeks.
The more complicated situation is the magstripe scenario.

Magstripe cards suffer from hundreds of different vulnerabilities and yet it's the most popular method of payment (at least in the USA).
We needed to come up with a solution that would be as convienent as magstripe while closing up the gaping security holes.
Also since magstripe is on it's way out eventually, we didn't want to invest in a lot of infrastructure that would be needed to produce magstripes with a custom IIN on them.

To do this we took a step back and analyzed all the known financial attack vectors and engineered a system that we hope is immune to them.

The first thing with magstripe is that ANY card will work, anything with a standard readable track 1 or track 2 data line ought to work.  Yes you can enroll your visa or mastercard, but you can also enroll an old gift card, a loyalty card from your favorite gas station, even your drivers license or library card.  We call this the "Any Card" method.  If it's readable in an MSR, then it will work for you.

When you enroll the card, the card info contained in the track is converted into an enrollmentID.  This enrollmentID is an SHA-256 hash of an SHA-256 hash of the number.  In addition to the enrollmentID your service will assign you a UUID, we've taken to calling this a userID, but it can be literally anything that uniquely identifies you to your chosen service provider (you can be your own service provider BTW).

The enrollmentID is hashed with the userID and used as a seed to an ecdsa key, the private portion of the key is discarded at this time and the public portion is used to calculate a public bitcoin address.
This way no bitcoin private key is ever stored.

Finally the stock enrollmentID is used to calculate an AES key which is used for encrypting traffic on the messaging system.

Now let's see how this comes together from a POS perspective.

Jimmy swipes his card at the POS terminal and selects OpenPay as a tender type (just like he might select credit or debit).
The card number is passed from the POS terminal to the merchant gateway.  The gateway is connected to the OpenPay network which is an XMPP based onion routing network.
The card number is used to generate an enrollmentID and an AES key.  A request for payment is generated by the gateway, and encrypted with the newly generated AES key.  It is then timestamped (default TTL for messages is 5 minutes) and handed to the messaging service.  All the messaging service does is relay any received messages to all contacts in it's contact list.

Eventually Jimmy's service provider (which could just as easily be software running on his phone, as it could be a separate company) pickups up the message via it's messaging service.  All incoming messages are routed to the authentication service which tries exactly once to decrypt the message using all the AES key's it's in charge of.  If the message decrypts correctly then the authentication service begins authenticating the validity of the request using one or more authentication modules.
Planned authentication modules include SMS, XMPP, hardware key based 2 factor, and static PIN.  There is also the possibility of accepting PINless transactions, but that's up to the service provider and the user.

Jimmy was configured for SMS so he receives a message containing a PIN and enters that into the pin pad.  The message follows the same path as before and it ends up at Jimmy's service provider.

From here the path is essentially the same as with EMV, a public key is returned, a list of unspent transactions is queried and used to build a BTC transaction (all using different modules running in their own memory space), finally a transaction is constructed and sent to the signing service along with the enrollmentID and the userID.  The primary difference being that with "Any Card" the signing service is residing on a server somewhere and not on the physical card.  Also the signing service doesn't actually have access to any private keys, unlike EMV where the keys are strored on the card itself.  The bitcoin private key is reconstituted on the fly using the enrollmentID and userID and is then used to sign the transaction.  The signed transaction is then sent back to the merchant gateway, which hands it off to the merchants service provider for validation.

I know it sounds complex, but the implementation is actually pretty simple.  It's more or less a matter of who does what at what stages of the pipeline,
I'll keep everyone informed here as the various modules & services are completed, enjoy!

I have been reading some of your earlier posts and this is a very interesting project.
(I don't understand all the POS protocol but then the software stack will hide a lot of that)

I presume that you will initially be concentrating on magstripe for the North American market ?
I am in the EU and it is all Chip n Pin over here now - I honestly cannot remember the last time someone swiped one of my cards.

Actually I prefer Linux to BSD myself.  But the CFS attack against AES  is specific to linux and it's potential impact cannot be discounted.  It doesn't necessarily require root privileges to execute and can result in the full recovery of the key in just a few minutes, which would be really, really bad, at least for that stage of the pipeline.
OpenBSD is the only recommended platform for deployment at the moment, although I don't see a problem with a properly secured linux such as SELinux so long as the kernel isn't running CFS.

I have crossposted this onto the bitcoinj mailing list as I sure they will all be interested.
More technical/ API details please !
:-)

Oh no, you just *had* to go and say BSD is more secure than Linux!  That caused epic flamewars, back in the Silver Age of Bitcoin (ie last summer).

Good thing that jgraham isn't around to hear about it.  He'd have a conniption fit. 

OpenPay will be officially entering pre-launch next week.  I will be posting the URL for the Open Payment Alliance website as soon as the Pre-launch is ready.

Pre-launch will be comprised of 3 primary phases.

The first stage is the "Burn in" phase, we will be laying out the infrastructure and hooking all the pieces together.  It is expected to last 2-4 weeks.  During this time anyone who wants to participate will receive hands on assistance in getting set up and connected to the network.

The second stage will be the "Shake Down" phase, this will be a sort of wargames period.  The Open Payment Alliance will pre-load the network with up to 1000 bitcoins, all of which will be constantly traversing the network.  The bitcoins on the network will all be real and they will be involved in binding transactions that will be occurring during this phase.  The purpose is to try and break (or break into) the system.   Anything you can come up with in terms of an attack will be fair game on the network during this time.  Our goal during this time is to learn how well the network and our reference stack can withstand sustained assaults, attacks and threats.  All the money you can capture during this phase will belong to you, no questions asked.  Our most significant goal is to learn how to analyze and defend against the attacks, so while we would appreciate any information you can provide, it's not strictly necessary.  This period is expected to last 1 to 2 months and during this time there will be a public scoreboard on the OPA website where you can see who got away with what and how they did it, (in as much as we are able to determine these facts).

The third stage is the Alpha test phase.  During this phase we will be primarily focused on bringing real merchants online.  Service providers who wish to bring merchants online during the Alpha test will be given direct one on one systems analysis, IT consulting, software support and even low or no cost custom software development if needed, to hook their customers and existing services into the OpenPay network.  The Open Payment Alliance will cover the software development and customization costs to bring on merchants of any size.****  This period is expected to last up to 6 months or until we have 1,000 unique merchants using the system, whichever comes first.

What is OpenPay?...

For those who do not know about it already, OpenPay is a new EMV compatible payment network that rides on top of the bitcoin network, and uses bitcoins as a currency agnostic interchange medium.
The end result of OpenPay is that you will be able to spend your bitcoins at any merchant that is able to accept Visa or Mastercard.

For the consumer, OpenPay means you will be able to use an EMV chip & pin smartcard, an NFC capable device such as your smartphone (there will even be a magstripe card option for those of us still in the dark ages) to spend your bitcoins at your local merchant.

For merchants, OpenPay means you will be able to accept payment in your choice of currency (BTC, Local, or other), with no network fees* or fear of charge-backs. 
There are also no restrictions on what can be sold or transacted on the network, if it's legal in your jurisdiction then it's allowed on the network (The anonymity and security aspects mean we have no idea who is transacting what, where or why.  We are not encouraging illegal behavior here, just saying that OpenPay is designed to be highly resistant to tin pot dictators, tyrannical governments and peeping spouses.  The only way we could do that is to create a pure common carrier network with high strength encryption, and complete anonymity.  Still the transactions all settle and finalize on the bitcoin network so don't do anything illegal please.) .

For service providers such as mining pools, banks, and currency exchanges (or people that want to start one or be their own), OpenPay is designed to be an essentially unbreakable, low cost business opportunity and value added service for your clients.
This is because the OpenPay stack is comprised of a series of modules aka services that are designed to be highly secure, very hard to crack and of little or no value on their own.
In other words an attacker trying to crack an OpenPay deployment would spend a very long time trying to do so, only to find out they were wasting their time; they would need to compromise your whole deployment before gaining anything of any value and even that would be highly questionable.  OpenPay's security model is not dependent upon any component or collection of components, and even services within a single deployment always assume all the other services are already compromised and therefore it all runs in a 0 trust mode.  There is no security through obscurity,
This means that an entity running the OpenPay stack in it's recommended configuration should not be susceptible to the kinds of attacks and break ins we have seen lately.

Features...

Security -
The OpenPay network is designed to be free of any viable attack vectors by utilizing security industry best practices at each stage of the payment processing pipeline.
The OpenPay network features strong anonymity via the use of a P2P based Onion routing model (similar to TOR).
All messages on the network are encrypted using AES and are unreadable by anyone except the sender and intended receiver**.
Offnetwork (anything not traversing the internet) Interprocess communication is handled via SSL/TLS and a certificate restricted ACL.

Opportunity -
OpenPay is completely de-centralized, the Open Payment Alliance is a volunteer organization tasked solely with the development of the OpenPay reference implementation and standard.  This means that service providers are expected to come online over time and provide the actual services on the network.  In a nutshell, it means anyone can be their own bank, or they can work with their existing institution, it's totally up to the participants.  No centralization means no central bank or other authority to dictate what can and cannot happen to your money.  It also means that anyone with the necessary skills and an entrepreneurial bent can begin offering their own services over OpenPay without the "blessing" of a central authority***.

OpenPay's design and reference implementation are completely open, and will be released under the terms of the GPL.
Anyone can run their own payment processing node on the system, detailed deployment instructions will be made available, along with best practice recommendations.
OpenPay features a built in deposit insurance system.  Service providers who choose to participate will receive 100% deposit insurance coverage for all bitcoins held in OpenPay enabled accounts.


Caveats & Fine Print...
*OpenPay has no network fees, if you choose a service provider they may charge you a payment processing fee, read your contract carefully.
**There is a known side channel attack against AES on Linux servers that use the "Completely Fair Scheduler" (CFS), Windows is well known as a security nightmare.  OpenBSD is our recommended deployment platform.  The reference implementation is written in Java and will run on anything that has a JVM, including *BSD, Android/Chrome OS, all flavors of Linux, Windows and ought to run just fine on OS/X.  Still you need to make sure you properly secure your servers, nothing can protect you completely once an attacker gets root or administrative privileges.  We get around it to a great degree by running several separate, low value services on separate physical servers.  Still if you don't have a computer security background you should hire someone who does to manage your deployment, don't run unnecessary risks.
***No central authority also means no one to vet out scammers and other bad apples.  Please do your homework on any entity before signing a contract or giving them your money.
**** The offer for free development and support is limited to merchants who have a physical retail presence.  We will still assist web based merchants with shopping cart integration etc, but the offer is primarily intended to help offline retailers accept OpenPay & Bitcoins as painlessly as possible.