Hello from our NGI Architects

 

_

Marvin

We hereby confirm that:

• pi-lar GmbH is not under liquidation or is not an enterprise under difficulty according to the Commission Regulation No 651/2014, art. 2.18
• The project neuropil is based on the original works and going forward any foreseen developments are free from third party rights, or they are clearly stated
• It is not excluded from the possibility of obtaining EU funding under the provisions of both national and EU law, or by a decision of both national or EU authority,
• All statements embodied in the Declaration of honour have been understood and accepted.

 

Cologne, 12.03.2021

 

_

Security
of the Past:
Limitations

  

 

_ only protection of bilateral IP connections

_ not protecting different data objects, but apis

_ unsuited for rapid change of

   data owners / new data channels

_

Security
of the Past:
Limitations

  

_

Security
of the Past:
Limitations

  

 

_ static design: build once, run forever

 

_ new requirements vs. security design

 

_ introduce security exceptions on change

_

too
bad

Security
of the Future:
Zero Trust

  

 

_ trust perimeter has changed

 

_ fragmented information (flows) need protection

 

_ authn/authz must be possible everywhere

 

_ data objects governed by
   external/internal access policies (AP)

_

Security
of the Future:
Zero Trust

 

 

Security
of the Future:
Zero Trust

  

 

_  defines trust levels for data objects
    or smaller groups

 

_  fine grained access to objects possible

 

_  more insights means minimizing risk

 

_  Never trust, always verify

_

 

better

 

Security for Complex Ecosystems:
Zero Trust & Access Policy

  

_ data object interactions main driver

   for future IT architecture

_ devices produce and consume data
   at the same time

_ respect different data owners per device

   if one fails, all suffer!

_

Security of Ecosystems:
Zero Trust, IDSA,

AccesPolicies

 

 

_

Security of Ecosystems:
Zero Trust, AccesPolicies

 

 

_ business agility: enables your company
   to adapt and survive

 

_ switch to a different service provider is easy

 

_ change policies in days (rather than months)

 

_ enables data reduction and data economy

_

much better

Data Sovereignty

  

 

_The capability of an individual or an organization to have control

over their personal and business data. This entails that they should

be able to know which party holds which data, under what conditions (purpose, duration, reward), where data is kept, and are able to re-use

the data at other places.

 

Source: Data Sovereignty Now

_

 

team digital sovereignty

 

Transparent data communication

should be available to everyone!

  

 

_

_ secure, sovereign and sustainable data integration

 

_ small, secure connector library

 

_ a decentralized identity space enabling privacy

_ connects everything: devices, edge, processes, applications, users, enterprises

_

Our Approach:

A trusted B2B Mesh Network

  

Security First

_ digital identities

_ dual encryption layer

_ attribute based access control

_ decentralized access delegation

 

... and more

_

Privacy First

_ stacked identities (realm / audience)

_ addressing hash based

_ DHT to protect metadata discovery

 

... and more

_

no more gateways

decentralized
P2P networks

Trusted B2B mesh network

Easy to use

_ installed as a OS library

_ connect once, communicate globally

_ python / lua binding available

_ identity / data based routing

 

... and more

_

Benefits

  

_ stay secure behind closed firewalls

_ standardized security measures

_ limit packet size / throughput

_ "blind broker" nodes

_

_

_ neuropil.org

protocol development & standardization

technical security stack definition

responsible disclosure handling

 

_ neuropil.io

base service layer

organizational security definition / enforcement

compliance & reviews

 

_ neuropil.com

​Add-On business services

Consulting & Development

Building our Organizational Foundation

with Pointer

_ neuropil.org / approx. 60.000 €

 

_ protocol definition & verification (6 months)

 

_ protocol documentation & standardization (6 months)

 

_ creation of governance body / structures (6 months)

 

_ foundation of European social enterprise

 

_

_

Strengthening our Technical Foundation

with Pointer:

Protocol definition & verification (6 months) / approx. 15.000 €

 

_ distributed time measurements (reusing existing definitions)

• re-use DHT and existing NTP structures
• use neighbor nodes and latencies / jitter to set local time
• either as a standalone node, or in combined mode

_

Strengthening our Technical Foundation

with Pointer:

Protocol definition & verification (6 months) / approx. 15.000 €

 

_ distributed time measurements (reusing existing definitions)

• re-use DHT and existing NTP structures
• use neighbor nodes and latencies / jitter to set local time
• either as a standalone node, or in combined mode

_

Strengthening our Technical Foundation

with Pointer:

Protocol definition & verification (6 months) / approx. 20.000 €

 

_definition of the realm protocol messages

• a „realm“ is a separate digital entity / identity
• Acting either as an authentication, authorization or accounting service
• similar to a PKI, but more powerful in ad hoc scenarios allowing to remote control small devices

_

Strengthening our Technical Foundation

with Pointer:

Protocol definition & verification (6 months) / approx. 15.000 €

 

_macaroons are better than cookies

• allows to verify authorization credentials in distributed environments
• definition of attribute verifier

 

_

Easy-to-use

_ hiding cryptographic complexity

_ installed as a OS library

_ remote token attestation

_ python / lua binding available

_ supporting

_ organizational security (e.g. SIEM)

_ enterprise architecture map (e.g. RAMI 4.0)

_ and more

 

 

_

Blake2b("urn:this:is:my:test:identity") =>   0x00000000 0x11111111 0x22222222 0x33333333

• This resulting hash is just obfuscating the string
• For a real digital identity this hash value would be based on the signature of its token
• There is a 1-to-1 relationship between the string and it hash value.
• An attacker still need to know the string, reverse search will be hard (the string should have more than 20 characters)

 

Blake2b("urn:handle:authorization:request") =>   0x11111111 0x22222222 0x33333333 0x44444444

• There will be many realms that would like to use this "subject" to receive authorization requests from related identities
• If this string is used as a "subject", then there is an potential overlap with others using the same subject
• lets transform this into a personalized hash value:

   0x11111111 0x22222222 0x33333333 0x44444444

+ 0x00000000 0x11111111 0x22222222 0x33333333

   0x11111111 0x33333333 0x55555555 0x77777777

• By summing the two hash values (treating each part as a cyclic number), personalized hashes are possible
• This is still not privacy preserving, everybody knowing my identity can subtract this value from other "subjects" hashes

_

_

 

• lets transform this into a truly privacy preserving personalized hash value by adding random noise:

 

   0x11111111 0x33333333 0x55555555 0x77777777

+ 0x12345678 0x88888888 0x33333333 0x98761234

   0x23456789 0xbbbbbbbb 0x88888888 0x1fed89ab

 

• assume that the random variable we added is only known to us
• we can distribute this random variable to our peers with end-to-end encrypted data channel
• we can change this random variable any time end redistribute it
• we could add more hash values, and we can use a different random value per "subject"

 

Please note: the derived hash values must only used to identify the correct data channel, data set, identity.

 

• Question: Is addition or cryptographic blake2b hashing more "expensive" ?
• Addition allows us to combine already pre-computed hash values into a new hash

_

<= add one random garbage value

_

 

let's apply the concept to our data channels

Blake2b("urn:this:is:my:test:identity")

+ Blake2b("urn:this:is:your:test:identity")

+ Blake2b("AES256-GCM")

+ Blake2b("urn:this:is:our:test:subject")

identifies a private aes256 encrypted data channel

 

• changing e.g. the encryption also changes the resulting hash value, and therefore also the routing through the mesh

 

let's apply the concept to versioning data channels​

Blake2b("urn:this:is:my:test:subject")

+ Blake2b("version=1.2")

+ random garbage value

identifies a private version 1.2 hash value

• incrementing version numbers will change the resulting hash value
• ​intermediate nodes not capable of interpreting the hash value will just forward messages to other peers
• ​we don't have to introduce additional routing concepts, the hash value is self contained

_