decentralized-identity / confidential-storage

Confidential Storage Specification and Implementation
https://identity.foundation/confidential-storage/
Apache License 2.0
80 stars 23 forks source link

Prevent bypassing authorization provided at higher layers by directly accessing lower layers #71

Open venu2062 opened 4 years ago

venu2062 commented 4 years ago

Should we just rely on encryption and let anyone request any cipher text (I would suggest the answer is no)...

Redundancy in security is not going to hurt, I suppose.

But if such an authorization is to be supported, bypassing it by directly accessing the lower level layer should be prevented. Otherwise, it creates a false sense of security - can be damaging in case a higher level layer does not reinforce it.

This can be done by having the layer supporting authorization authenticated at the lower level or the data encrypted by the authorizing layer so that a parallel service cannot bypass authorization.

Originally posted by @venu2062 in https://github.com/decentralized-identity/secure-data-store/issues/51#issuecomment-637701977

venu2062 commented 4 years ago

Followup comments:

Comment by @OR13

Comment by @venu2062

venu2062 commented 4 years ago

To resurrect the safe deposit box analogy:

Safe deposit boxes have three layers of protection:

1) Access authorization in the form of signature matching 2) Key held by the bank 3) Key held by the individual accessing the box

In the layering, we can think of it as follows:

1) Authorization to access the vault is controlled in the physical storage layer (layer 1) 2) Equivalent of the bank's key should be in the logical data layer - to prevent this layer from being bypassed (layer 2 or higher) - layer providing the granular authorization 3) User's key is equivalent to the key held at the client/application layer

With this structure, the additional granular authorization provided in higher layers can be relied on as long as the providers of these layers can be trusted.

OR13 commented 4 years ago

@venu2062 I think we will address this on the next call, when we discuss authorization.