Taking back ownership of your data

The convenience of hosted solutions for digital assets and archiving can hide a major problem; do you control the data you own? KnowledgeArc.Network’s decentralized architecture ensures you are in full control of your data.

Do you really own your data?

Hosting digital assets in the cloud has become a popular and cost-effective solution. But what happens when you decide the host you are with is no longer providing the level of service you expect?

You may think migration is as simple as your existing host dumping the data out to a backup file and making it available for your new provider to restore. Unfortunately, the reality isn’t that simple; closed source applications often have proprietary formats which make them difficult or even impossible to import into other systems.

On the other hand, some open source systems are customized, but the customizations might not be publicly available, so backups only capture a subset of your data. For example, there are archive hosting providers who have built multi-tenant data storage on top of a single application. Databases in such a system cannot simply be lifted and re-implemented on other infrastructure. This results in broken features and crucial data being excluded from the system.

Even if migrating from one system to another runs smoothly, complex backups and time-consuming debugging are often required. Export/import tools need constant maintenance, but with niche products such as digital asset systems, maintenance of these ancillary tools can often be ignored.

A distributed solution

The KnowledgeArc.Network platform makes centralized storage obsolete. Data is replicated in multiple locations whilst still being owned of the original creator.

Replication allows application managers, developers and system administrators to build a variety of user experiences on top of the data. There is no need to set up complex data structures, import and export data, or work around missing data. Instead, the user simply replicates an existing database and works directly on top of it.

Data can also remain private even though it is stored in a public way. By encrypting data, the owner is the only one with access to this information and can grant other users varying degrees of control. For example, perhaps certain users might only be able to read data. Others might be able to update existing data but not delete it.

Centralized vs decentralized

Recently there has been a move to more centralized archiving solutions. Instead of disparate systems talking to one another or federated systems being established to support a “go-to” repository of information, a number of governments and bureaucracies are pushing for everything to be centralized. This results in a stagnation of innovation and, more importantly, a single point of failure.

Figure 1: Legacy Archives

KnowledgeArc.Network decentralized databases will capture the best of both worlds; every archive is unique but their records can easily be merged into a single, federated archive. This federated archive can then be replicated further so that multiple user interfaces can be created on top of the same data.

KnowledgeArc.Network captures the best of every model. Decentralized, independent databases provide institutions with full control and ownership of their data. Federated archives simply merge distributed databases into a single data store. And, finally, the entire community can build their own user experiences on top of any archived data by simply replicating an existing database.

Figure 2: Decentralized Archive

Self-signed certificates with local root CA

This tutorial briefly covers the creating and trusting your own certificate authority (CA) for issuing self-signed SSL certificates, and is designed to work with OribitDB’s new REST API HTTP/2 push services.

This tutorial is aimed at Unix-based systems, in particular Ubuntu and other Debian-based Linux distributions so you will need to modify the commands for your own platform. All code examples are intended to be copied and pasted directly to the command line and will generate certificates in your current working directory.

To get started, we are going to create a root certificate which we will use to sign additional SSL certificates with.

First, create your root CA private key:

openssl genrsa -des3 -out rootSSL.key 2048
Generating RSA private key, 2048 bit long modulus
………………+++
………………………………………………………………………+++
e is 65537 (0x010001)
Enter pass phrase for rootSSL.key:

You will be prompted for a password. Be sure to specify one that is long enough as you may encounter errors if your password is too short.

Next, use your CA private key to create a root certificate:

openssl req -x509 -new -nodes -key rootSSL.key -sha256 -days 1024 -out rootSSL.pem

Once launched, you will need to re-enter the password you assigned to your private key:

Enter pass phrase for rootSSL.key:

If successful, provide information about your certificate:

 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 Country Name (2 letter code) [AU]:
 State or Province Name (full name) [Some-State]:WA
 Locality Name (eg, city) []:
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:
 Organizational Unit Name (eg, section) []:
 Common Name (e.g. server FQDN or YOUR name) []:localhost
 Email Address []:

You are now ready to install the new CA certificate into your CA trust store. The following commands will copy the root certificate into Ubuntu’s CA store so you may need to modify the paths if you are on a different distribution or OS platform:

sudo mkdir /usr/local/share/ca-certificates/extra
sudo cp rootSSL.pem \/usr/local/share/ca-certificates/extra/rootSSL.crt
sudo update-ca-certificates

Now it is time to generate a certificate for your development environment. Create a private key for your new certificate:

openssl req \
 -new -sha256 -nodes \
 -out localhost.csr \
 -newkey rsa:2048 -keyout localhost.key \
 -subj "/C=AU/ST=WA/L=City/O=Organization/OU=OrganizationUnit/CN=localhost/emailAddress=demo@example.com"

Next, create the certificate, signing it with your Root CA:

openssl x509 \
 -req \
 -in localhost.csr \
 -CA rootSSL.pem -CAkey rootSSL.key -CAcreateserial \
 -out localhost.crt \
 -days 500 \
 -sha256 \
 -extfile <(echo " \
    [ v3_ca ]\n \
    authorityKeyIdentifier=keyid,issuer\n \
    basicConstraints=CA:FALSE\n \
    keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment\n \
    subjectAltName=DNS:localhost \
   ")

Your SSL certificate is now ready for use. To use it with OrbitDB’s REST API, launch the cli.js script with the flags –https-key and –https-cert, using the new localhost.key and localhost.crt files we just created:

node src/cli.js api --ipfs-host localhost --orbitdb-dir ./orbitdb --https-cert ./localhost.crt --https-key ./localhost.key

The certificates should validate against your Root CA when used with tools such as curl:

curl -vs --http2 -X POST https://localhost:3000/db/my-feed --data 'create=true' --data 'type=feed'
 successfully set certificate verify locations:
 CAfile: /etc/ssl/certs/ca-certificates.crt
 CApath: /etc/ssl/certs
 ...
 SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
 ALPN, server accepted to use h2
 Server certificate:
 subject: C=AU; ST=WA; L=Ellenbrook; O=Organization; OU=OrganizationUnit; CN=localhost; emailAddress=demo@example.com
 start date: May 25 14:56:35 2019 GMT
 expire date: Oct  6 14:56:35 2020 GMT
 common name: localhost (matched)
 issuer: C=AU; ST=WA; L=Ellenbrook; O=Internet Widgits Pty Ltd; CN=Local Certificate
 SSL certificate verify ok. 

In the above, you can see the CA being loaded from the correct location (/etc/ssl/certs) and details about the certificate (Server certificate:).

You can now successfully run the new OrbitDB HTTP API with self-signed certificates on your development environment.

References

How to get HTTPS working in localhost development environment, secureend.com, https://reactpaths.com/how-to-get-https-working-in-localhost-development-environment-f17de34af046

Decentralizing DSpace Backups using IPFS

With the Archive token (ARCH) deployed and https://knowledgearc.io live, the team is now focussed on implementing our decentralized archiving ecosystem.

In the beginning…

KnowledgeArc.Network is already under development. We have spent the past year tokenizing various academic material. Using a combination of ERC721 non-fungible tokens, IPFS and OrbitDB, we have been developing an open-source, distributed archiving ecosystem that can be implemented by anyone. Using our Archive token, community members will be incentivized to participate in the creation of a truly open, decentralized academic platform.

Read More