I have an use case where i need to send data to multiple counter parties but the parties need to be kept anonymous of each other . After the endorsements are collected back from the counter parties i need to commit the whole transaction. The atomicity of the whole transaction needs to be maintained.
What is the best way to achieve this with Flows.
For this, you need to use confidential identities. Confidential identities are represented in states by the AnonymousParty class:
class MyState(val party: AnonymousParty): ContractState {
override val participants = listOf<AnonymousParty>(party)
}
The difference between a Party and an AnonymousParty is that AnonymousParty identifies participants by public key only. As long as each transaction participant generates a new public key for the transaction, their identity, and therefore their involvement in the state, will be secret.
To create a transaction involving confidential identities, you must do the following:
One party who initiates the flow - let's call her Alice - must know the identity of all the counterparties (to know whom to gather signatures from)
Alice runs the SwapIdentitiesFlow with each counterparty to automate the creation of confidential identities for all the participants
Alice uses these confidential identities in building the transaction
Alice gathers signatures from all the counterparties
Alice finalises the transaction
Each party will end up with the transaction in their vault, but each party is only identified by an anonymous public key, so the involvement of each party is kept secret from their peers.
You can find docs about this API here: https://docs.corda.net/api-identity.html. You can find an example usage of confidential identities here: https://github.com/joeldudleyr3/whistleblower.
Related
I want to regularly check that output state is not consumed by tampering, so I want to ask the notary whether the state is consumed or not. Is this possible ?
I believe you would need to write a flow that is executed by the corda notary which then performs the vault query on the notary. This is listed as an experimental feature in the corda docs so you may want to rethink how you are designing your cordapp first. I haven't utilised this feature a great deal before myself so I'm unsure how well it's supported but it should work. This does mean however you are likely to be running your own corda network as you need control over how the notary is deployed.
It may be more appropriate to have another trusted node or party that has visibility and is a signer on the ContractState's that you want to check. Your third party would then also have a responder flow that performs a vault query on it's own vault and responds back to initiator.
You can query a node for consumed states by specifying Vault.StateStatus in the vault query API
val vaultSnapshot = proxy.vaultQueryBy<ContractState>(
QueryCriteria.VaultQueryCriteria(Vault.StateStatus.UNCONSUMED))
How does a notary/node verify that a specific flow has been called when it receives the transaction?
Does this mean Corda can guarantee that the flow has not been modified from what was stated in the corresponding Cordapp?
In detail:
It's a DLT (Distributed Ledger Technology); so in a sense, you can't really trust anyone.
The notary doesn't receive flows, it receives transactions and makes sure that there is no double-spend (i.e. consumed inputs are not being consumed again).
Even if you gave a node your CorDapp, it can override the responder flow. See links below.
Wrong assumptions about responder flows: https://www.corda.net/blog/corda-flow-responder-wrong-assumptions/
Configuring responder flows: https://docs.corda.net/flow-overriding.html
Overriding flows from external CorDapps: https://dzone.com/articles/extending-and-overriding-flows-from-external-corda
When you send and receive data between an initiator and its responders; the received data (on both ends) is considered untrusted; you must unwrap it and validate it: https://docs.corda.net/api-flows.html#receive
So in short:
Your initiator must validate any received data from the responder(s).
Your responder must validate any received data from the initiator; plus if you expect the initiator to be a certain entity, you must validate that the counter-party (that sent you the flow session) is who you expect it to be (e.g. flowSession.counterParty == "O=Good Org, L=London, C=UK").
Adel's answer covers the right ways to not trust your counterparties from the application flow level but there are also operational protections which can used. Strong contracts can help prevent badly formed transactions as Corda does not allow for unknown contracts in a well setup network.
The network parameters defines what smart contract cordapp jars are acceptable for validation. The most common form of contract constraints is signature constraints which means that any contract jar signed by the same developer key can be accepted. This prevents a malicious counterparty from forcing you to run weak validation: https://docs.corda.net/api-contract-constraints.html#signature-constraints
As of Corda 4 any unrecognized contract cordapp jar will not be trusted unless the node operator explicitly tells Corda to trust the jar. https://docs.corda.net/cordapp-build-systems.html#cordapp-contract-attachments Once a signature is trusted then any future jars signed by that signature will implicitly be trusted.
I have a couple of reliable collections across different stateful services. I need to access one reliable collection from another stateful service (e.g. Employees collection from Department stateful service).
Although the Employees collection is populated with data, when I try to get a reference to the collection
var myDictionary = await this.StateManager.GetOrAddAsync>("employees");
var allEmployees = await mydictionary.CreateEnumerableAsync(tx, EnumerationMode.Unordered)
var enum = allEmployees.GetAsyncEnumerator()
the enumeration count on allEmployees collection returns count of 0.
The same approach works correctly when I try to access the employees in Employee collection in the Employee stateful service.
This doesnt work when I try to access the employees in Employee collection in the Department stateful service.
Is this a correct way to access data across collections? If not what is the correct way?
A stateful service contains it's own state that can be accessed only with that service, it can't be shared with another stateful service. Don't think of it as a database. Each stateful service can contain multiple collections or queues, but that service owns that state. If you want to expose it, create an API using your favorite communication stack and make an API call from the other service.
Note: This is a security related question.
I am putting users in groups, which the name are moderately sensitive (database object ids).
I am sending messages to groups from the server side, never from client (that's why putting db object ids in the group's names was not a problem for me).
From my understanding, I am assuming that SignalR is managing groups deep inside its core, and communicate only with each Connections, but I am not sure.
So my questions are:
Does the groups name are well hidden from client?
Or is it possible for a User (from the client side), to discover in which Group(s) he belongs to? (and then potentially discover sensitive data if developer was assuming groups names where hidden/inaccessible)
Group names would only be exposed if you passed them to the client.
From the server side, SignalR has no API to maintain or expose this. You can maintain your own group names, thus any exposure would come from your own doing.
As far as security goes, that should be handled outside of SignalR.
You can however check out using roles to help if you need to restrict on specific methods such as (link):
[Authorize(Roles = "Admin")]
public class AdminAuthHub : Hub
{
}
Our company has a multi tenant asp.net web application. The application is 3 tier e.g. website,business and dataaccess. We hold the tenant id in session after the user logs in.
When we need to get a list of 'customers or orders' we pass the tenant id from the website to the business to the data access and then to the database (and query for customers or orders for that tenant). (almost every business function takes tenantId as a parameter)
Sometimes when creating new functions developers forget to add the tenant id from the website to the database, causing a security issue.
Is there a way we could do this so that the developers dont need to always remember to pass the tenant id.
Any suggestions on how best to resolve this issue.
public class CommonService
{
public int getTenantId()
{
//do your validations and error handlings
string tid = session["tenantId"] // or get it from customs claims principal or set it in a httpcontext.current.items
return tid;
}
}
Then use the service in every business object to get the tenant id and pass it to the data layer without depending on the developers to do it. Its a very big security hole, missing an tenantId might return data which the user is not supposed to see and might shutdown the company
It sounds like you are passing all the values around individually.
If you construct an object that you can pass around freely, you will always have the information you need. I would assume that the UserId is always associated with a tenant. Can you build a simple object, store it in the session and then pass it to all functions needing it.
class user{
int userID;
int tenantID;
}
If you have a value in the Session and you need it in the database queries, you have to propagate it through the tiers to the database queries.
If your developers sometimes forget to pass the value and they get security issues, that is actually not a security issue but a security feature.
If the database needs that id, then the business layer methods should have parameters for it. How can they forget it?
One approach would be to create a View per table per tenant (may not be practical depending on the number of tenants you have and how frequently they change) and deny access to the application to the underlying tables.
This article explains how to do this as well as several other approaches and their performance tradeoffs:
http://msdn.microsoft.com/en-us/library/aa479086.aspx