Topic: mgw - page 3. (Read 3794 times)

I am still in the mode of creating all the modules and once they are done, then we probably want to put one process per VM? I am assuming that once all the modules are done, isolating each of them is just a matter of installing things properly and setting up the firewalls to only allow the one task that each VM is doing.

I still have a horrible shortcut of invoking dogecoind via system("./dogecoind ") I am pretty sure that isnt the best way of doing it, but just havent had the chance to do the RPC thing. I am parsing the JSON output, so all that would stay the same. Though, my hardcoded parsing is also probably not the best way of doing things.

I also use a linear list for just about everything. At small numbers of transactions, its not a problem, but it wont scale with thousands of accounts. I am isolating all searches, so we can always replace it with a more efficient method.

This started out as a proof of concept, so it could use a refactoring by someone who knows all the best techniques.

For now, I will work on the control flow and ignore these issues until we have fully functioning gateway.

James

Edit: If my code just serves as a spec and has to be totally refactored, I am ok with that, in fact I would prefer that. I was thinking we could run the refactored version on one of the gateways and then we have two independent implementations so any bug in one wouldnt be replicated on all the gateways. Maybe we need two independent refactorings?

I guess the webpage is pretty isolated from any TOTP calculations, so it stays on a separate site.

I had thought that it somehow had to be passing sensitive info over the internet.

Looking at the code Ciyam gave me https://github.com/ciyam/ciyam/blob/master/src/crypt_stream.cpp#L173
it seems that if I have the secret for the user, I can generate the token needed.

I think I need C functions that I can call that will:

1. Generate acceptable random password to use, maybe just `openssl rand -base64 50` and then encrypt it with gateway's private key.

gateway publishes this in the AM response that binds the deposit address to NXT acct.

2. A function that takes as input the encrypted data and gateways private key and returns the TOTP

Then we need some sort of way for the website to send a request to the gateway with NXT acct# and user input token. If it is good, then the withdraw request is marked as approved. If error, this gets relayed back to webpage


James

That's bad security. You don't want to host the website on the gateway. The gateway should not run services that take arbitrary inputs.

The only thing that should run there is your software, and it would take it's input from NRS and dogecoind. You don't need any other input right? Only those two daemons plus internal communication between the gateways. So, not even dogecoind or nrs should run on the same machine/VM, it would just remotely communicate through RPC/JSON with them.

10000 NXT BOUNTY for google authenticator help


I am announcing a 10000 NXT bounty for someone to help me integrate google authenticator to the gateway. It will be paid when the gateway passes the community created test plan for multigateway.

I need someone that can do the webpages needed for account # and token input and the server side code that properly correlates that. along with whatever other help I need. Especially making sure the process is secure.

James

Edit: I need someone to host a webpage for users to put in their acct# and token and also a mechanism for gateway code interact with the webpage. Ultimately, the webpage will be moved to the gateway

antanst, aka Evil Bob impersonator, has raised a security weak spot in the current gateway design.
Each gateway currently generates a custom deposit address and when a deposit comes in, it immediately sweeps it to the main multisig acct. The duration of exposure is less than a second (could be set to 50 milliseconds), but it is exposure.

So, I am changing things so that there is no sweeping into a main account. All custom deposit addresses will be 2 of 3 multisig. This will require a fair amount of internal changes, but it eliminates the in transit deposit exposure. Now, all deposits will go directly into a multisig account and stay there until a withdraw request needs the funds.

The multigateway isnt perfect, but I will do everything possible to make sure it is as safe as I can make it.

Does anybody know how to setup google authenticator? I think it works by having a seed value associated with each user. I can put the encrypted value of this seed in the AM response to the user. Then for people who choose to activate this feature, they would need to go to a webpage, input their NXT acct # and authenticator token

With such a setup, can anybody think of how Evil Bob can attack the gateway? All I can think of it a spite DDos attack that would just slow things down, but no money lost. Any other attack vectors? Can someone forge the NXT acct # in the "sender" field in a confirmed AM transaction?

James

Because I have to issue the max possible DOGE assets upon creation. So there are 1 billion DOGE assets, but without a matching deposit, we cannot let them into the wild. Even if we had assets that can be created incrementally, what is to stop an attacker from just creating more assets after the server is compromised.

So, my solution is to put AE asset balance auditing into nodecoin and all the gateways. If there is an unexpected discrepancy, all withdraws are stopped. If the compromised asset cant be reclaimed, then the plan is to do an emergency swap with a DOGENXTASSET.2. Everybody will get their old DOGE asset swapped for the new version based on verified balance. A total mess to say the least, but the alternative is to just let them take the asset and drain the deposit accts.

Also, by not having a sweep acct, I cannot just look at the deposit addrs unspent outputs to find unprocessed deposits. I need to correlate all prior AE transfers with matching deposits and any unmatched deposits needs to trigger the Asset issuance. It is a much more complicated thing, but as you say, reliance on single gateway isnt good enough.

I also want to add google authenticator option for withdrawals.

James

If you keep a 1 DOGE <-> 1 DOGENXTASSET analogy, why would you want to keep track of NXT AE balances? Unless there's a compromise, there will always be as many assets as DOGE's deposited, regardless of who has them.

The real issue isn't if (or rather when) a gateway is compromised and how one can secure it. It is the reliance on a single gateway.


I can set up a FreeBSD jail this way (it's like a VM). Files can be read only inside the VM. One can harden a server pretty much if convenience isn't a concern. But again, isn't the real issue.

antanst, who is now the designated Evil Bob, has raised the issue of a gateway server being compromised.

I read about some security hardened servers somewhere, but I cant find the URL. It was setup so that the software running on it couldnt be changed, without some elaborate process. I am pretty sure amazon offered some such service. If anybody knows about this, please post.

Is it worth implementing 2 of 3 multisig for the transitory deposit accounts? Hmmm. Actually, I think we could avoid the sweep account entirely. The withdrawals would gather up unspent txouts from the required custom multisig accts. I could even make the user be one of the signers on the custom multisig acct, but not sure what utility that has. As people trade assets, their NXT AE balance will diverge from what they deposited. Then again, someone who deposits 10 BTC is a lot more likely to have significantly more NXT assets than someone who deposits 0.1 BTC

I cant rely on bitcoind to keep track of account deposits anymore and will need to correlate all NXT asset transfers with all deposits. But I do like having lots of multisig accts, it sure makes it much less of a target. I can even prioritize the withdrawals to even out the balances of all the multisig accts, that way each one will contain 1/N of the total deposits, at least as best as can be matched up with withdrawals.

antanst, I think you will be happy that the deposit 50 millisecond vulnerability will be gone. We will have realtime NXT asset reconciliations and mechanisms to immediately freeze any withdrawals if we detect anomalies.

How else can we improve this?

James

That's where I'm focusing at. It doesn't matter if it's 50 ms or 5000 seconds. If the gateway is compromised, the attacker can steal the deposits destined to this gateway. In effect, you have secured the DOGE storage pool via multisig transactions, but since the deposits are vulnerable to a compromise while on transit, you don't gain anything security-wise.


I believe the key question is if it can be used as a truly decentralized ALTCOIN<->NXT exchange, in which case it can't. It has a centralized point of failure.

Granted, building a decentralized cross-chain exchange is an extremely difficult problem, which I'm not sure if it's solvable with the current limitations of coin daemons and NXT AE.  Unfortunately, I do not have any suggestions right now, but I'll keep thinking about it. It's worth it, and you seem to be on the right path.

The withdraw address is set ahead of time, so it does not have to be sent with the withdrawal. If a new withdraw address is desired, it can be changed with an AM sent to the gateway. The moment any of the NXT assets are transferred without a corresponding validating transaction, alerts will be generated and all withdrawals of that asset will be frozen.

Two gateways would need to be compromised at the same time to get at the shared deposit acct due to the multisig. Deposits in transit at that gateway could be stolen, but the polling for deposits can be set to 50 milliseconds, so the window of opportunity is pretty small. The recommendation is to locate the server in a security hardened facility or use one of the secure amazon servers used for credit card processing.

We can also use cold multisig wallets when the shared multisig acct gets too big.

Granted, this is not perfect, but how does it compare to a centralized exchange? That is the key question isnt it?

James

Edit: do you have any suggestions on how to improve things?

Does it matter for how long? If there's a compromise, user's coins are going bye-bye, because you've placed the trust on a single gateway.


Sure, but I thought the point was to make it easy. People can always mitigate against an exchange failure by depositing onto another exchange anyway.


So up to now we have one asset transfer to an account of a gateway, plus a message to the gateway that says "Withdraw" and presumably contains the DOGE withdraw address as well?

And again, if the gateway gets compromised, the attacker can steal the assets? If have understood the whole process, there are three (and only three) gateways, and even if one of them gets compromised, there are time windows where the attacker can both steal the DOGE deposits to this gateway and the NXT assets used for withdrawals.

Each specific deposit is handled by one gateway and then swept into multisig, but any of the gateways can be selected for handling the deposit.

For deposits, my design is as vulnerable as a centralized exchange, but this is only for the brief time that a deposit is in transit. People can mitigate against this by splitting up their deposit into three and sending increments to all three.

I thought about letting the users directly send to the multisig, but then we would need to limit each user to using a single source address for making deposits as there would be no other way to correlate deposits with customers. It also exposes the multisig account to uncontrolled unspent txouts, which impacts the method of generating withdrawals. There are some scenarios where deposits would have to be delayed for a bit to clear out withdrawals and if we didn't control the deposits going in, we would not be able to manage this. What happens after the server gets restarted? Every single direct deposit to the mutltisig would have to be correlated with NXT acct, I think this would require some sort of database, which brings up a whole host of issues that I avoid with my simpler design.

I could have created a different multisig for each person, but that opens up an entirely new level of complexity and would introduce a much higher chance of bugs, which is really indistinguishable from a security risk. The simpler the design, the fewer chances for bugs. I wanted the gateway to be as stateless as possible.

It is a tradeoff, but since the user has a way of mitigating risk, all of the other factors won out for this method. For the truly paranoid, we can have a client automatically breakup the deposit into three sets and then incrementally send fragments of that. At any given time, the risk is limited to the time the deposit is in transit only. It is not like the funds will be sitting there for any length of time.

Certainly much easier than any of ripples half dozen+ gateways, but I am also viewing all of the various exchanges balances/finances page as gateways. I think relying on NXT account # in AM is more secure than email confirmations.
I guess my thinking is that it is much easier to use than any of the ripple gateways and just as easy to use as centralized exchange gateways, but more secure than they are

James

So the user deposits DOGE to an address that is solely handled by one gateway, and afterwards the amount is transferred to a multisig account? What if this gateway gets compromised? Why not give the user directly a multisig acount to deposit in the first place?


What gateways are you referring to? Ripple's?

it is time to recall c,linux and java.

I will dig into this for some time, and let you know how I can contribute afterwards.
This thread is great to get started, thank you James and mcjavar.

I cleaned up the code a bit and now the get_dogeaddr.c is around 100 lines of C

git clone https://github.com/jl777/multigateway
cd multigateway
chmod +x run.sh
./run.sh
./get_dogeaddr [gatewayid]

James

yup. I'll be putting FreeRider up on github tomorrow. I really want to do s.t. else for a break. That sounds good!



 

1. AM means Arbitrary Message, it is really a way to publish data on the blockchain. I check the first four bytes for the GATEWAY_SIG code and if it matches, assume it is a data packet for the gateway. All communications to the gateway are via the blockchain.

2. I wanted to do 4 of 5, but the current bitcoin network treats anything over 3 signers as a non-standard transaction and few of the miners will propagate it. For dogecoind, it simply gags on anything over 3.

The only way you can talk to the gateway is by using a sendMessage NXT API
http://wiki.nxtcrypto.org/wiki/Nxt_API#Arbitrary_Message_System_Operations

The data needs to be a gateway_AM data structure. The C code has char *AM_get_coindeposit_address(int timestamp,int gatewayid,char *nxtaddr,char *withdrawaddr,char *userpubkey)

This shows exactly how to create and send a request to bind NXTaddr with DOGE withdrawal addr. It will then publish a corresponding AM with the deposit address. The C code loops scanning all AM's for the gateway signature and when it finds the one with the deposit address, it terminates.

Now there are two completely separate processes, deposit and withdraw.

Deposit
1. user sends DOGE to the address returned by gateway in the AM data
2. the selected gateway (each gateway has different deposit address) detects the deposit and transfers the amount to the shared multisig acct and at the same time issues the corresponding amount of DOGE and milliDOGE assets. Amount is rounded to nearest .001 and TXFEE is subtracted

Withdraw
1. user transfers DOGE or milliDOGE asset to the gateway (or DOGE asset issuer)
2. the selected gateway notices the withdraw request and posts an AM with the details
3. all three gateways process the withdraw request and add it to an internal queue
4. All withdraws are put into a single global queue for all withdraws to avoid any parallel changes to balances
5. the three servers agree on which withdraw request to process and generate a rawtransaction to satisfy it
6. all three servers compare their rawtransaction with the other servers and if it is IDENTICAL to the byte, the selected server signs a rawtransaction that was already signed by one of the other gateways and broadcasts it to DOGE network and also sends an AM to the NXT blockchain that the withdraw was completed
7. all three servers mark the withdraw request as completed and go on to the next on in the queue

So, quite a lot of stuff happening behind the scenes, but as far as the user is concerned, the DOGE deposit address is directly linked to the NXT AE and the NXT AE "transfer" link is directly connected to their DOGE wallet registered as the withdraw address.

I designed this to be the easiest to use gateway out of all the gateways that are out there, but one that is more secure.

James

P.S. If you point out that the above does not match the picture, you got me. I just thought the pic was cool and it is something that might or might not get done in a parallel project

Ok. I'm going to make a whole lot of questions, and some of them might seem strange, but I skipped many posts of the huge NXT thread...so I appreciate your patience :-)

1. What does "AM" stand for? Asset Management?

2. Why 2-3 multisig transactions? Is there support for M-N multisig transactions, where 2>M>N, at least in the RPC API of dogecoind or in {Bit,Lite}coind?

Can you explain the general workflow, and the input/outputs of each computer in the workflow?


Let's say I have some Doge's. I talk to the input server. I assume that the "Input Server" will be the one that hosts a web site or an API server, right? So I'm given a DOGE M-N multisig address, in which I should deposit the coins. This address has been generated with all the N private keys coming from the N Trusted Gateways. I also give my NXT account, in which I want my assets transferred to.

I deposit the doge's in the address. The trusted gateways coordinate together, M of them sign the transaction and withdraw the DOGE's into a private address. Then some (how many?) "DOGENXT" assets are created, and given back to the user to his NXT account.

Are the above right so far?