MaidSafe Dev Update :safe: 29th March 2016

[happybeing]

@neo this is the issue that grappled with in SAFEpress, and my solution was not elegant.

Essentially app users write data to their own space.

Data that is to belong to the app is avoided, instead it will belong to the app administrator - in the SAFEpress example this administrator is the blog owner, not the app author. So no keys in the app to steal. The app is run either by user (post comments etc) or the administrator(s) (create blog pages, write blog posts, accept/delete comments etc).

But how does a user write data to the administrators space?

They can’t. A user writes a comment to their own space, and the app sends a message to the blog administrator who can then decide how the app handles these - e.g auto accepts, review and accept/ignore, pass through a filter and accept/ignore etc.

This scheme makes spam comments much harder (user pays to store and to send messages which are also hard to spam - see safe messaging RFC), so I expect most systems of this kind could safely accept all comments, perhaps just adding certain filters to flag up suspect comments for manual approval.

[Traktion]

Only time for a short answer here, but:

• the shopper creates a transaction SD
• the shopper transfers ownership of the transaction SD to the shop owner
• the shop owner processes the transaction SD
• the shop owner updates the SD with any specifics regarding authorisation, delivery time, etc.

Ultimately, the network only acts as an agent to users (shop owners and shoppers here). The app can just run using the persona of the user interacting with it. Said interactions can also be scripted.

Until the network can execute code autonomously, any logic must be executed by a user connected to the network. At least this is my understanding.

[neo]

Nah forget it.

I just wanted to know what the dev team had programmed in.

It would be great to have APPs do real time updates of SDs owned by the APP “owner/whatever”

[Traktion]

@neo

So your saying that a customer has to manually transfer the SD to the shop owner.

Great that won’t endear SAFE to customers.

Manually? No - via the shopper (client) component of the application. The customer just clicks 'buy and the software creates/transfers any SDs.

@neo

So there goes automated systems. EG those used for digital downloads.

There goes real time updates of stock remaining. Customers have no idea if stock is left.

How so? The shop owner (server) component can monitor for the SDs coming their way and respond to them. This would require the server component to be running g somewhere (thin client like - even a mobile phone, for example).

If atomic transactions are required (stock control), it is going to get more tricky, but not impossible.

One example would be creating SDs for stock items, which are transferred to the customer as a sort of purchase order. Other clients could then just read how many SDs are remaining in stock. As SD ownership is atomically transferred, this would prevent the selling of stock which didn’t exist.

Not sure what the rest of your post said, as you deleted it. Hope the above is useful pondering though.

Edit: to add, I am hoping a user will be able to listen for changes to any SDs they own. This would help when writing interactive applications, without having to resort to polling.

[neo]

@Traktion

How so? The shop owner (server) component can monitor for the SDs coming their way and respond to them. This would require the server component to be running g somewhere (thin client like - even a mobile phone, for example).

Certainly not ideal, may as well have a server receiving messages and responding. IE we go back to server client systems.

@Traktion

If atomic transactions are required (stock control), it is going to get more tricky, but not impossible.

But if my original question to the devs was not buried in work-a-rounds, then maybe we can see if proper real time update systems can be securely implemented.

@Traktion

Not sure what the rest of your post said, as you deleted it. Hope the above is useful pondering though

It is still workarounds.

Please understand I can do fully secure order updates and semi-real time updates, but it is a total work-a-round and not really utilise the power of SAFE. Simple work-a-round is to use messaging and a always on computer as a server.

---

If the devs implement a system where the keys can be stored in the meta data for the APP and the network uses allows indirect authorisation and the APP code need never have the keys and the malicious user cannot manipulate SDs.

The APP is stored in immutable chunks and thus keys are safe and the APP is safe.

---

This hinges on secure update of SDs that is not owned by the person running the APP, but the person who setup the APP.

[Seneca]

@neo

If the devs implement a system where the keys can be stored in the meta data for the APP and the network uses allows indirect authorisation and the APP code need never have the keys and the malicious user cannot manipulate SDs.

The APP is stored in immutable chunks and thus keys are safe and the APP is safe.

Doesn’t this come down to smart contract functionality? Because the network (close groups) would have to validate that the input for this protected SD object is correctly produced according to the immutable app code. If I understand you correctly here.

[neo]

@Seneca

Doesn’t this come down to smart contract functionality? Because the network (close groups) would have to validate that the input for this protected SD object is correctly produced according to the immutable app code. If I understand you correctly here.

Well the APP’s PtD address is kept in the meta data, so why not the SD owner keys. It does not need smart contracts. The data managers have already validated the meta data, so why not the keys.

---

but maybe the devs have already thought of a solution and have implemented it.

And that is all I am asking.

[dirvine]

@neo

but maybe the devs have already thought of a solution and have implemented it.

Not 100% here on the question really. I think it is if the network can authorise transfers or updates to SD items. At the moment it cannot, but there are reserved SD’s for such purposes (network created/edited items).

The RFC process will push this idea and others I am sure. The team are nowhere near SD at the moment. Crust routing and vaults then the client guys in launcher and client. So the data is what it is right now. SD has a pretty massive place in the network though and group consensus is a real thing. So making an owner a group could work amongst others. It needs some poking though as all the API does for SD, it will be the most useful part for app devs but also the most mistreated I bet.

Sorry for delay in getting to this. Busy night/morning

[Traktion]

@neo

Certainly not ideal, may as well have a server receiving messages and responding. IE we go back to server client systems.

It may not be ideal, but it should work on the MVP. I would say it is more of a thin, distributed server, which is progress in some ways.

@neo

If the devs implement a system where the keys can be stored in the meta data for the APP and the network uses allows indirect authorisation and the APP code need never have the keys and the malicious user cannot manipulate SDs.

The APP is stored in immutable chunks and thus keys are safe and the APP is safe.

I didn’t think this would be possible without distributed computing, but maybe I jumped to that conclusion.

[abittner]

I have noticed, my git pull just fails on QA at the moment, all other repos pull just fine.
Anyone?

~/maidsafe.org/QA> git pull
*** Please tell me who you are.
Run
git config --global user.email “you@example.com”
git config --global user.name “Your Name”
to set your account’s default identity.
Omit --global to set the identity only in this repository.
fatal: empty ident name (for testuser@linux.site) not allowed

Thanks.

[neo]

@Traktion

It may not be ideal, but it should work on the MVP. I would say it is more of a thin, distributed server, which is progress in some ways.

Certainly small progress but missing the true benefits of SAFE.

@Traktion

but maybe I jumped to that conclusion.

I think you might have. To explain what I meant would take too much space in the topic. But in essence I was saying that since the APP cannot be modified by a malicious user then the PtD coin address and keys associated with that copy of the APP is safe.

[neo]

@dirvine

Not 100% here on the question really.

Question is (even if put on back burner till later)

• APP needs to update some real time values stored in SD objects
• users run the APP and the APP updates those SD objects in real time
• APP implements mechanism to prevent two updates at the same time
• The SD objects of necessity need to be owned by the APP’s owner
• If the APP has the credentials to the SD objects in its code/data area then a malicious (or interested person) could extract them from the memory snapshot while the APP is running

My question was simply is there going to be a mechanism that the credentials can be stored/derived from outside of the APPs code/data. Maybe stored with the PtD pay address in the meta data area.?

OR will we have to use work-a-rounds to do this suffering delays in now-not-real time updates etc.

[cretz]

@neo

If the APP has the credentials to the SD objects in its code/data area then a malicious (or interested person) could extract them from the memory snapshot while the APP is running

Things fall apart here. That’s like saying “Well, my keyboard enters my password and a local app can just listen to keys”. Local apps have a lot of privs. Short of employing an HSM there’s not much you can do IMO. I know I might have to store shared keys or private keys for my apps’ use inside of safe for cross-device and cross-user use. But I also know just about every crypto lib out there needs the keys in memory as a byte array to perform encryption/decryption.

I mean, if we go down the road of local attacks you can do, there are a ton. I can impersonate an app simply by providing the same app info. Heck, I can repaint the HWND to show whatever I want. I can grab the session ID for your bank website you are logged in to and impersonate you that way. Maybe I am misunderstanding the fear here. Are you saying that it’s ok for the maidsafe-built software to store this stuff in mem but not other apps?

[neo]

Yea I know all that.

This is specifically something for SDs and many APPs can run without any security keys needed. So if we can have SD accessed with the credentials derived outside of the APP’s code, then a whole lot more APPs can run without having to worry about losing info.

Lets face it, all the good APPs will be open sourced and no security info needed, since the APP will mostly act as an agent for the user and thus it is the users credentials being used. The malicious user already knows those credentials since they belong to them.

I think it would be bad programming practice to have security keys in an APP that is either Open Sourced or runs purely on the users PC.

I give it 1 day from release before the security info is extracted for every significant APP publicised. I base that on the current state of affairs. Hell the Chinese would probably have them in 1 hour if they thought it worthwhile.

There is a reason on shared computer systems that the Operating system segments its operations from the user code.

BUT you give me a great idea for APPs on SAFE. A secure data object (or many) that holds security keys etc, that can be indexed by the APP but not read by the APP/user. So the APP does

• asks the system to create/update a SD and gives the index to the SD credentials to the network, rather than credentials
• This special securedata object is tried to the specific copy of the APP. Since the APP is stored in immutable chunks the network has a one-to-one connection between special securedata object and the specific (copy/version of) APP

SO now the only hole to plug is an injection attack where a more capable cracker can inject code into the APP. Once that is solved then we can have similar operations to server-client databases without the server at all.

I am sure that crypto can solve even the injection attack [quote=“cretz, post:53, topic:8294”]
Are you saying that it’s ok for the maidsafe-built software to store this stuff in mem but not other apps?
[/quote]

I am not even implying that “store this stuff in mem” But a mechanism that allows a APP to be totally open sourced but also have secure credentials that cannot be found by looking at code or memory or asking SAFE.

Impersonating Apps in SAFE is not possible, since the APP is stored on SAFE immutably, SAFE can set a one-to-one relationship between APP and its meta-data.

The only problem to solve then would be to detect if the APP is modified on the user’s machine (code injection attack). I am sure/hopeful crypto could come to the rescue somehow, because we have the user’s group to help there. Even a double variable salted checksum of the code can help detect code changes, but I am wondering if this has even been considered yet. APPs are very important and the security of SDs equally important. Otherwise every SD operated on will have to be owned by the user and transferred to the other and this eliminates real-time updates and only delayed-time updates applications by reverting back to servers and server-client operations

[cretz]

@neo

But a mechanism that allows a APP to be totally open sourced but also have secure credentials that cannot be found by looking at code or memory or asking SAFE.

This is what happens when my apps store data today. SD data is used to make NFS metadata and my apps are open sourced. The key is they do it on behalf of the user. So technically apps are open sourced without storing security info in source and using SD today (and really the only thing that they get from SAFE is a key to encrypt data to the launcher, it is unrelated to the the safe_ffi and safe_core uses). Maybe I am misunderstanding here too.

@neo

Impersonating Apps in SAFE is not possible, since the APP is stored on SAFE immutably

I have successfully shown that I can impersonate another app and have access to data that is supposed to be user-and-app-specific. Maybe I misunderstand what you mean.

[neo]

@cretz

The key is they do it on behalf of the user.

@neo

Lets face it, all the good APPs will be open sourced and no security info needed, since the APP will mostly act as an agent for the user and thus it is the users credentials being used. The malicious user already knows those credentials since they belong to them.

Yea I mentioned that

@cretz

I have successfully shown that I can impersonate another app and have access to data that is supposed to be user-and-app-specific. Maybe I misunderstand what you mean.

I think you might have. I am referencing the SAFE as it will be. The pre-MVP has some security flaws

In SAFE the APPs are stored as immutable chunks making a file (datamapped) and as such if I reference that version/copy of the file, it cannot be impersonated. The system cannot rewrite those chunks. So the meta-data for each chunk is for that chuck and the relationship cannot be changed, just like the chunk cannot be changed.

So if SAFE uses a datamap for that specific copy &/or version of the APP (file) then it cannot have changed since it was written. Impossible if SAFE is working correctly.

SAFE then can associate any meta-data to a specific chunk.

Thus if I copy an APP to run my version of whatever, changed obviously to hold my (company/app) specific name etc, which defeats dedup. Then you cannot impersonate to SAFE that your copy is that copy and access my copy’s meta-data which currently can hold the PtD coin address.

From there I suggested that we also setup a mechanism where the credentials for SDs be stored too. Or maybe the address of a specialised system tagged SD that holds APP specific info that can be indexed.

See my previous post about issues over code injections is would need to be solved too to make it secure from malicious attack.

[Traktion]

@neo

I think you might have. I am referencing the SAFE as it will be. The pre-MVP has some security flaws

In SAFE the APPs are stored as immutable chunks making a file (datamapped) and as such if I reference that version/copy of the file, it cannot be impersonated. The system cannot rewrite those chunks. So the meta-data for each chunk is for that chuck and the relationship cannot be changed, just like the chunk cannot be changed.

So if SAFE uses a datamap for that specific copy &/or version of the APP (file) then it cannot have changed since it was written. Impossible if SAFE is working correctly.

I think this may help to prevent apps from being impersonated by others, but I am not sure it will help us run anything as a different (app) user.

Currently, we only define app details to the launcher, which then presents them to the user. Once the user accepts the app authentication request, the launcher then allows the app to update associated or shared data. We can see this here: https://maidsafe.readme.io/docs/auth

If the launcher took app details directly from immutable data, with the launcher just being given the data key, this could help to prevent spoofing of app details. However, what would stop a different app providing the same data key, then running some different code afterwards, as the authenticated user?

In short, the launcher doesn’t validate the source of the code or execute it - it just grants access for the application to act on behalf of the user.

Maybe app details and it’s code could reside in the same immutable chunk, but presumably the launcher would then need to know what to do with the code itself - it would need to execute the code within the launcher itself. Maybe that is feasible (and would help to prevent app spoofing), with a defined language for doing so, but we would still only be running the app as the user logged in via the launcher.

What is missing for me, is how the launcher can run any code on behalf of another user. It only has access to the network using the credentials the user provided to it, which it then grants apps permission to use.

[neo]

That is a different discussion really. From the point of view of what I am discussing then if an APP is running on the users machine then one assumes if the users gives the APP permission to act on its behalf then there is no need for the user to spoof his/her details.

I am more interested in the APP being able to use the credentials of the APP’s “owner” to (re)write SD objects in the “owners name” without the user being able to crack it. Not concerned with users protection in this discussion.

It would seem that even having credentials for the APP “owner” derived in the group rather than the users PC still has the problem of “code injection” being able to tell the group to write data to the SDs.

[Seneca]

How do you secure these keys in meta from abuse by the vault groups?

[cretz]

@neo

I am more interested in the APP being able to use the credentials of the APP’s “owner” to (re)write SD objects in the “owners name” without the user being able to crack it. Not concerned with users protection in this discussion.

OK, I finally get what you are saying here. You are saying an app has data on its own regardless of who the user is. I don’t agree with that. I don’t agree the app has an owner except for “tagging” requests for app dev safecoin. I believe everything should be done on behalf of the logged in user. That means the data has an owner, not the app. The next obvious question is how a group of users alter records. I see collections of “owners” on https://github.com/maidsafe/rfcs/blob/master/proposed/0016-launcher-data-types-api/0016-launcher-data-types-api.md#update-structured-data but there is too little detail there and I have not dug into the SD impl in safe_core. Otherwise, I would expect apps to adopt novel approaches to encryption on top of safe, so if a group of users needs to do things that isn’t supported by the network, the app implements shamir, shared PKI, or even homomorphic encryption if it’s simple mutations like addition. That’s just my high level thought without having read the SD details.