Handling accounts and private keys within company or organisation

[freigeist]

Hello.

What would be the best way to handle the accounts and private keys within company or organisation?

Normally companies are using own centralised or 3rd party software where user accounts could be activated or deactivated at will by the software administrator (owner) or the account can be restored and password could be reset if credentials are lost by the user.

In case of a block chain software accounts this is not the case so the question is how the loose of user credetials could be resolved?

Lets suppose this case maybe it will give an clearer idea about the problem:

Company A) is using some business software.
This business software creates some public data reports that needs to be shared with other companies.
To do that Company A) needs to create a NEM account that will be used to appostile or sign the documents (reports) issued by the business software that they use.
To do that Company A) needs to validate the created NEM account (do some sort of KYC) so that other entities gathering that info from that account know
who is the issuer of the reports.

The company does that all and works fine for some time issuing signed reports.
After some time for whatever reason access to NEM account is lost or hacked and the company can’t sign the reports any more so other parties can’t trust
the issued reports any more.
In this case what would be the solution to that issue?

Also what would be the bet way to KYC a company?
Can a company do a self KYC procedure?

Example:
create account sign data of the company (name, registry id number , var number, address , website, link to the appositle document, etc…)
and put that data on that link in the appostile

Or the KYC of the company should be done by 3rd party for example company X) that would keep records of all the companies.

I hope you understand my question and that someone with more experience could give more insight into the matter.

Thanks.

[gevs]

I tend to think that with multisig, all the issues are resolved.

In case of a block chain software accounts this is not the case so the question is how the loose of user credetials could be resolved?

With multisig on NEM, in case you setup n-of-n rather than m-of-n, that is for example using 3-of-3, 4-of-4, 5-of-5, etc… you need only n-1 cosignatories to modify the account, this is to relax the dead-account problem.

In this case what would be the solution to that issue?

Using multisignature, this would mean that you need to lose/hack multiple private keys, which is really not that probable. Securing accounts with a 3-of-5 for instance, you would be authorized to lose up to 2 keys ^^

Also what would be the bet way to KYC a company?

Probably not related to NEM ? Unsure what you mean but there is registers online for companies: http://www.listofcompaniesin.com/

[freigeist]

Hello and thanks for your fast reply.

I tend to think that with multisig, all the issues are resolved.

Well thought that I would receive this is kind of simplistic answer.
But could you please give some more info about multisig and the methodoligies
that should be employed in that matter. I have put the questions below.

With multisig on NEM, in case you setup n-of-n rather than m-of-n, that is for example using 3-of-3, 4-of-4, 5-of-5, etc… you need only n-1 cosignatories to modify the account, this is to relax the dead-account problem.

I’m not sure that I understand how this n-of-n works.
It would be possible for example having 3 accounts (A,B,C) to setup 3-of-3 multi signature? Can any of this 3 account be a sender and consignatory account at the same time?

Using multisignature, this would mean that you need to lose/hack multiple private keys, which is really not that probable. Securing accounts with a 3-of-5 for instance, you would be authorized to lose up to 2 keys ^^

Let me understand by this simple example m-of-n .
Having accounts A,B,C,D,E,F where A is sender and the B,C,D,E,F are consignatories and the multisig is set 3-of-5 which means any 3 account from the list (B,C,D,E,F) would be enough to sign the transaction from account A? right?
But in that case loosing the access or private key of account A is enough to fuck the whole thing. Right?

Probably not related to NEM ? Unsure what you mean but there is registers online for companies: http://www.listofcompaniesin.com/

I know there are registers usually national registers but don’t you think that someone could fake and register with existing valid data from the register by not being the company owner of this data. For example User X gives data of company Y even if user X is not owner nor employee of that company. The question is how you match a blockchain account address to a legal entity in a trustworthy way?

Lest suppose that you have an IT company and your company has a product based on NEM blockchain which other companies can use to validate some outputs.
To use that product the company needs to create a NEM account(s) multisig if needed
and to do that they need to register with their data together with their NEM address into the system. So the question is how will you avoid that scenario from above with user X company Y?

The other thing is who should have custody of this multisig NEM accounts in this company that uses your product?
Should the manager the secretary or IT department take care of that?
Should your IT company that supplies the product always be a consignatory of the accounts used by your clients?

How would you organise that?
I ask this because I do not have experience in that matter any you know
how it ended with that Japanese exchange where they were sending private key over unencrypted email

So any constructive advice is welcome.
Maybe people at @luxtag_official could have some advice about that last part or my post.

Thanks.

[gevs]

It would be possible for example having 3 accounts (A,B,C) to setup 3-of-3

You need 4 accounts because the “multisig” account is a normal account (say “D”) that is converted to a multisig with A, B and C as cosigners.

3-of-5 which means any 3 account from the list (B,C,D,E,F) would be enough to sign the transaction from account A? right?

Any of them can issue and that will cou t as 1 cosignature, but 2 other will have to cosign before the transaction is effectively confirmed (and included in a block).

With a 3-of-5, if you lose 2 private keys, you still have 3 so you are fine.

The question is how you match a blockchain account address to a legal entity in a trustworthy way?

Identity is not one of the best use cases for blockchain, keep in mind that cryptos (most of them at least), are pseudonymous.

So i agree with your point here but I actually dont think a company registry, nor an identity registry, have their place in the core protocol. Those are use case that will mostly happen second layer with some kind of authority, or registry…

What I can propose to you as a scenario is to have a namespace for your family, say “evias” and under this, each family member has its own subnamespace that is linked to their address (through aliases). That would also be applicable for company employees.

The other thing is who should have custody of this multisig NEM accounts in this company that uses your product?

Who do you want to trust to tell you the truth? Thats exactly the problem here, you are using a decentralized mechanism to fulfill a centralized certification which is not really compatible in my honest opinion.

Should the manager the secretary or IT department take care of that?

With catapult, it could be “all or not valid”. With catapult multisig can be multi level which means the IT director can delegate the decision to other 3 or 5 or 10 of hos team members.

I will post a bettet explanation of multisig here on monday, currently on a run and on phone

[jtey1]

Maybe people at @luxtag_official could have some advice about that last part or my post.

Full disclosure, I work at @luxtag_official. However the following comments I make are my personal views on the subject.

To do that Company A) needs to validate the created NEM account (do some sort of KYC) so that other entities gathering that info from that account know
who is the issuer of the reports.

You can publish a namespace under that account, and announce it as the company’s official namespace.

The company does that all and works fine for some time issuing signed reports.
After some time for whatever reason access to NEM account is lost or hacked and the company can’t sign the reports any more so other parties can’t trust
the issued reports any more.
In this case what would be the solution to that issue?

On a decentralized system, unfortunately nothing. The best you can do is to make the incident as public as possible. It works the same for Certificate Authority and Revocation lists. All major browsers will try to keep as up-to-date as possible revoke list.

Having accounts A,B,C,D,E,F where A is sender and the B,C,D,E,F are consignatories and the multisig is set 3-of-5 which means any 3 account from the list (B,C,D,E,F) would be enough to sign the transaction from account A? right?
But in that case loosing the access or private key of account A is enough to fuck the whole thing. Right?

If A is a multisig account, it’s private key is longer valid on the blockchain. However if you use account A’s private key on another chain, then it could be another attack vector (Side note: never reuse private keys).

The other thing is who should have custody of this multisig NEM accounts in this company that uses your product?
Should the manager the secretary or IT department take care of that?
Should your IT company that supplies the product always be a consignatory of the accounts used by your clients?

Management of private keys is a sliding scale based on the perceived risk. On the one hand, you want to provide some level of security, on the other hand, you do not want it to be a hindrance to others doing work. For example the cash till at the counter has a simple lock compared to a bank vault which has multiple mechanical parts… For management of private keys, you have many options from writing it down on a piece of paper to using hardware wallets, or HSMs.

how it ended with that Japanese exchange where they were sending private key over unencrypted email

No comment on this

Should the manager the secretary or IT department take care of that?

With catapult, it could be “all or not valid”. With catapult multisig can be multi level which means the IT director can delegate the decision to other 3 or 5 or 10 of hos team members.

My opinion is that for a centralized application, using multisig to enforce a contract is overkill and adds unnecessary complexity. A better way would be to secure a signing server/hardware wallet, and then internally run an audit trail on who uses it, touches it or even looks at it . That way you have fewer private keys to control access to (which also means easier to spot unintended activities)

However, using multisig to secure an application is good practice to prevent a single point of failure. For example, how you would implement 2FA in an organization.

[freigeist]

Hello

@gevs @jtey1 thanks for you answers.
The idea here was to build as simple protocol to exchange validated data between
verified business entities without using a central authority and only using a public chain.

From your answers it does not seem possible to implement something like this without using
a middlemen (central authority) to verify business entities.
I’ll have to give more thoughts on this

[gevs]

Use apostille to push company certifications and you have your decentralized central authority

But i doubt that this is really valuable as there is no KYC in place etc. And you would need to build all this side too to make sure companies are legit and registry is up to date, etc…

[freigeist]

1. That were my thoughts at the beginning to use apostille for kind of “self verifying” the source.

2. speaking of this wouldn’t the there be the same problem when it comes to communication between private and public chains?
   Example Company A on (private chain mijin) <=> public chain (catapult) <=> Company B (private chain mijin)

How company B knows that A is a valid source of Information and the opposite?
How is this resolved? That still needs central KYC Authority!

[gevs]

A is the origin but it is private. Source for B is public chain.

Private chains have a unique “generationHash” that permits identifying networks.

As far as I can tell - with your scenario, private network A will be timestamping or anchoring on public chain and thats what B will actually use as its source, because A is private.

It is hypothetical and may be a bit to few details are laid out here about how this could work. I dont see a real problem in implementing a company registry thats leverages NEM features.