Suppose that in my "network" of users each node can create only one hashed code (generated with the node's id).
Now, node A sends to node B this hashed code. node A is no longer the owner, but B is.
still, it's just a string, so node A decide to trick the system and sends also to node C the same code. how can node C know that A made an illegal operation?
can C validate the operation only by communicating with node A? (without server or communication with other nodes)
thanks
I think your question is:
How can I prevent node id theft/forgery in a p2p overlay network?
The answer is:
By use of public key cryptography.
Related
My apps using bonjour service to conversation with each other via local network.
I am facing a problem on Xcode12 with OS14 device.
A device publish a service with server type name depends on self device IP address
(example: 192.168.33.20 -> _1921683320._tcp)
B device searching a service with service type depends on A device IP address
(example: _1921683320._tcp)
According to apple document..From OS14~
https://developer.apple.com/documentation/multipeerconnectivity
Important
Apps that use the local network must provide a usage string in their Info.plist with the key NSLocalNetworkUsageDescription. Apps that use Bonjour must also declare the services they browse, using the NSBonjourServices key.
because my service type name is named by local network ip, it is changeable base on local network setting, so I am thinking about to using wildcard to define the service type name.
example: _*._tcp
but seems wildcard is not available on this definition.(I tried it)
I am also thinking about changing the naming method on A device
(example: 192.168.33.20 -> _20._tcp)
and add _1.tcp ~ _255.tcp to info-plist
But if I changed the naming method, B device could not find A device until version up.
Any idea for this problem? Please help.
I'm currently working through the same issue - Bonjour service name is dynamically created based off the iPad name to form a local mesh network. The conclusion that I have came to is com.apple.developer.networking.multicast is required for this to function without completely overhauling how all that logic is done. (More info here)
You will have to request permission from apple by filling out a form here. Let me know if this works for you!
The thing I am finding is, you "might" not be able to use a wildcard, but you can put multiple entries in the plist:
Item 0 _multicastapp0-p._tcp
Item 1 _multicastapp1-p._tcp
Item 2 _multicastapp2-p._tcp
Item 3 _multicastapp3-p._tcp
etc
Item N _multicastappN-p._tcp
So for some reason if you are trying to have multiple "Groups" of 8 or have a device have it's own "collection" i.e. be a server and have 3 devices connect to that, you can.
I haven't "fully" tested but I am going to be doing this in my apps, I did test using multiple keys tho, but not fully, no errors...
We are working with token and accounts at Corda with Kotlin. I will detail the scenario to clarify.
We have a node1 and a node2.
We created a "OurTokenType" that extends from TokenType.
We created two accounts (seller and buyer) on node1 and shared them with node2.
By the business rule of the application, node2 is the one who issues the tokens (FungibleToken), and the issue worked correctly. In the end, node1 and node2 have access to the FungibleStates for the issue transaction.
Our problem is in the transfer of these tokens. When we try to transfer the tokens from the account seller to the buyer.
In our scenario, the transfer of tokens can happen on node1 or node2.
When we transfer through node1, which is the host of the accounts, we can use the MoveFungibleTokensFlow class that works and the FungibleStates on node1 are updated to the correct value. However, when we added node2 as an observer in the observerSessions parameter, the FungibleStates on node2 were not updated correctly.
And when we do the transfer by node2, which is NOT the host of the accounts, using the MoveFungibleTokensFlow class, it doesn't work, it generates an exception of com.r3.corda.lib.tokens.selection.InsufficientBalanceException: Insufficient spendable states identified, even with balance .
My question is, can I use the MoveFungibleTokensFlow class to transfer between accounts even if they are on another host?
And when we run on the node that hosts the accounts, what is the problem to update the FungibleStates when using observerSessions?
Or if I must follow the example of the link https://github.com/corda/samples-kotlin/tree/master/Accounts/worldcupticketbooking?
MoveFungibleTokensFlow doesn't have an input parameter that specifies who's the source of the moved tokens, and that's because it considers the initiator of the flow as the source of the tokens.
class MoveFungibleTokensFlow
#JvmOverloads
constructor(
val partiesAndAmounts: List<PartyAndAmount<TokenType>>,
override val participantSessions: List<FlowSession>,
override val observerSessions: List<FlowSession> = emptyList(),
val queryCriteria: QueryCriteria? = null,
val changeHolder: AbstractParty? = null
) : AbstractMoveTokensFlow() {
You are not correct about "both node1 and node2 see the issued tokens", in FungibleToken the only participant is the holder of the tokens, so when tokens are issued to seller and buyer accounts, the only participant is the node that hosts those accounts (i.e. node1).
Going back to my first point, because only node1 has the issued tokens, and you're running the move flow on node2 (the flow consider node2 as the source of the tokens, but node2 doesn't have them); that's why you're getting the insufficient balance error.
Even if you added node2 as an observer when you issued the tokens to buyer and seller (i.e. both node1 and node2 have the resulting tokens); if you dig deep through the code of MoveFungibleTokensflow which inherits from AbstractMoveTokensFlow which relies on ObserverAwareFinalityFlow to sign the transaction, you'll see inside ObserverAwareFinalityFlow that it doesn't call CollectSignatures flow, it only signs the transaction locally (see here); meaning only the node that holds the private keys of the accounts can sign on the move command, and since node1 is the host of buyer and seller; then node1 is the owner of the private/public keys and only node1 can sign on behalf of buyer and seller. So even if you shared buyer and seller accounts with node2; only node1 can sign, and since you're calling MoveFungibleTokensFlow from node2 (your 2nd scenario), it will fail when it reaches the part where it needs to sign on behalf of seller (to move its tokens), because node2 doesn't own the private key of that account.
On a side note, when you call MoveFungibleTokesnFlow from node1 to move the tokens of seller to buyer; make sure that you supply a value for queryCriteria to select only the tokens that belong to seller; if you don't supply a value; then the flow will pick any tokens that are hosted on node1 so you might end up moving tokens that belong to other accounts.
Also make sure to supply a value for changeHolder, so that the change goes back to seller, if you keep it empty; any resulting change will be assigned to the initiating node (i.e node1) instead of the account.
You can find lots of helpful tips in my article on Tokens SDK.
Also, R3 recently released a free Corda course; it has a great section on Tokens SDK.
In order for you to be able to move tokens from seller to buyer using node1 or node2 you have to rely on the utility function addMoveTokens() instead of the ready flows (i.e. MoveFungibleTokensFlow) (because of the above mentioned reasons). So you have to create the transaction yourself, then add the tokens to be moved using addMoveTokens(), then you have to collect the signatures (of the seller) using CollectSignatures flow (the seller will sign in the responder flow); also you have to take care of finalizing the transaction.
Just to clarify the above flow, your flow should check if it's the host of the seller; then it can sign locally, if it's not the host; then you have to create a FlowSession with the host of the account so you can collect its signature (i.e. its approval to move the token that it holds).
Samples repo has some examples that use addMoveTokens(); I recommend spending some time to explore them.
Let me break down your question into two parts:
Observer session doesn't update automatically:
Here is an example of how we would trigger the update on the observer session: https://github.com/corda/samples-kotlin/blob/master/Tokens/stockpaydividend/workflows/src/main/kotlin/net/corda/samples/stockpaydividend/flows/AnnounceDividend.kt#L37
This will ensure the observer's token state is updated whenever the maintainer makes an update. (Note: only the maintainer should make the update, not the owner)
Fungible token transfer between two parties: Yes. it is doable. This line of code is the beginning of FungibleToken transfer in the worldcupticketbooking sample: https://github.com/corda/samples-kotlin/blob/master/Accounts/worldcupticketbooking/workflows/src/main/kotlin/com/t20worldcup/flows/DVPAccountsHostedOnDifferentNodes.kt#L102 It definitely works.
I see you mentioned that you had an error message on InsufficientBalanceException, if I were you, I would start digging in from there, and see which token is being queried exactly.
I am using Corda Version 4.
My CorDapp has four nodes - Notary node (validating), "Node A", "Node B" and "Node C".
Node A and Node B are to be designed as private nodes, being accessible to one user each.
Node C is a public node, accessible to 5 users.
From documentation in URL "https://github.com/corda/accounts", I understood that by using Corda Accounts the Node C can partition the vault into 5 subsets, where each subset represents an account or user.
To achieve this should I define accounts in node configuration in build.gradle?
Is there any example in the git?
RPC users are defined inside node.conf, where the user is able to connect to the node and call flows.
Accounts is something different, before Corda 4.3 a state would be owned by a party/node so for every user you had to have a node, with Accounts library they introduced a stated called AccountInfo which has a host field which is the node that hosts the account, UUID field (unique on network level), and name field (sort of a username) which is unique on host level (i.e. you can create an account devman on NodeA and account devman on NodeB and they are considered different).
Anyway, there are a lot of concepts in the Accounts library and it's not possible to answer them here, have a look at the IOU example using accounts: https://github.com/opticyclic/corda-accounts-demo
Also the library itself has 3 examples, I recommend looking at the GoldTrading one since it's the most simple one.
Why does the Node need the network-root-truststore.jks file at initial registration? What's the relashionship between this file and the nodekeystore.jks?
EDIT: Actually, I was meant that I didn't see the relashionship between the CSR and the network-root-truststore.jks file. Is it not possible to generate the Certificate Signing Request without this file?
network-root-truststore.jks-> This is the network operator's root CA.
nodekeystore.jks -> This contains nodes identity key pairs and certificates.
As you can see in the diagram. The Root CA for Doorman and Network Map are same. The node assumes 3 level hierarchy as you can see in the picture above. ( This got fixed in version 3.3 so you can have a n-level certificate hierarchy)
For initial registration with the doorman, you'd need to create a CSR request and send it to the doorman, the doorman will then return you the requestId, Using the provided requestId you'll ask the doorman if the CSR has been signed by him or not once done, Doorman will hand you over the node certificate like below
Once you've the node certificate signed by the doorman, you want to validate it (for this you'd need the RootCA Certificate which is inside the network-root-truststore.jks now you don't need it to create the CSR, but the certificate received must be validated, as result, you need this. Also, this prevents man in the middle attack.)and generate the TLS key pair and certificates.
The above process is automatically done by the corda node for you at the time of initial registration when you start the node using this command -> java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
One Important thing is you should remove or delete the network-root-truststore.jks file once you are done with the registration.
During live migration, the destination Compute Node has to perform some 'pre live migration' tasks, among them is the tap creation at the destination OVS.
I would like to know if once Nova creates such tap interface, is the port/tap status UP?.
This is the behavior I am experiencing, but I am not sure whether it is the default one or not?
In case it is, is it possible to delay such action to the 'post live-migrations tasks'. I am thinking of something like this
Pre Live-migration : Create port/tap interface at destination Compute Node, but status DOWN
Live-migration Post
Live-migration : Delete
port at source Compute Node, set port/tap interface at destination Compute Node UP
Thanks for your time
Best Regards,
Jorge Gomez