Please could you introduce yourself briefly and explain why you decided to become a part of Vereign’s story?
Hi all, my name is Gospodin Bodurov and I am Head Of Development in Vereign. I am a self-taught developer with strong experience in computer science and hard core backend development. Throughout the past years, I participated in multiple national and international programming contests, and I spent almost 7 years as backend developer. Five years ago I switched to management and cybersecurity as my main focus.
Could you explain what problem Vereign is solving from a technical perspective?Authenticity. If we think for the person as a broadcaster of digital information, we are building the trust in this information. So in short we can sign and verify almost all types of content that a living person can generate.
What are the key technical elements needed to achieve authentic interactions on the internet?
All elements of Cryptography – crypto keys, signatures, certificates, chain of trust, hardware tokens, distributed trust and many more.
Key management is a hard problem to solve: With passwords and email we have a centralized key which unlocks your online identity, but with key management systems backup is at the user’s hands and it might mean losing control of their online identity. How do you approach it from a technology standpoint?
In case of a lost device a.k.a. private keys, we have two approaches in mind. The first approach uses a 3rd party verification provider similar to CBFS. The second approach is to implement „social“ recovery using Shamir’s secret sharing scheme.
Identity is a core component of most Internet applications today. How will developers have the ability to integrate their products with Vereign?
The second way is to use our OAUTH2 server in order to gain backend access to the chosen user profile. With this profile we plan implementation of multiple crypto services similar to content crypto signing on the backend or authentication management for desktop and server side applications.
Last but not least, we plan to provide a mobile app, which can be used as an authenticator for 3rd party mobile apps.
Can a user use the same account with multiple devices and how does that work – sharing keys, new device enrollment (and confirmation from the original one)?
Yes, actually we have identity, but not accounts. We have profiles instead of accounts, where you can actually choose and share the information you want.
We are using the QR code approach in new devices enrollment, which means if you have already enrolled a device – this device, together with the backend generates a unique QR code and if you scan it with the new device you want to enroll, you just add the new device to your existing identity.
We do not have sharing keys, every device actually generates its own unique set of crypto keys and certificates. And we are signing these certificates in order to make a chain of trust attached to the identity for this device
Digital Signatures are part of identity. How are you implementing them and which aspects are you making better than existing solutions?
We are using the standard CMS based crypto container. This approach is based on the x509 crypto setup, together with the whole chain of trust paradigm.
For me personally, I like these two innovations we already implemented or have in mind. The first one is to actually generate a one time certificate and private key for every signed content interaction we have in the system (emails and documents for now).
The second one, is that we actually plan putting hash codes and statuses of our x509 certificates in the blockchain network, which will lead us to a distributed social Certification Authority model a.k.a. A distributed chain of trust.
We have another nice feature called the vCard – the vCard is your email footer but instead of only containing your avatar photo, we have contact information, together with a digital signature of the email embedded in.
In which parts of the product are you using blockchain and have you considered other viable alternatives?
At the moment we are using blockchain, mainly in our audit log (a.k.a. identity operations list). We already discussed the distributed Certification Authority use case. Another one is storing statuses for every interaction (emails and documents). The final one we have in mind is using Merkel trees to harden up our server logs.
Our usage of blockchain is entirely driven by its capability of key/value data storage. So every key/value data storage, which has similar features of blockchain (append only database) will do the job for us.
Data protection regulations are becoming a necessary requirement for all technology products. What are the technical measures you take to make sure personal data is protected?
Having our own key management key setup, we have two ways of actually providing Data Regulation appliance. The first one is already implemented – we have end-to-end signing and verification mechanism, because of our crypto model (storing the crypto data in the user’s device).
The second one we have in mind, is implementation of end-to-end encryption mechanisms for all of our data – interactions, personal user claims, etc.
We support all standard Data Regulation operations at the moment.
Why are federated instances important for a web of trust and data protection?
In terms of data protection – you can host your own instance – which means you are the owner of your data.
In terms of web of trust – every federation instance will have its own x509 root certificate, and this root certificates will be signed by Vereign’s chain of trust. As an additional backward compatibility to old style Certification Authorities, we shall sign the attributes of every x509 certificate generated (locally in this federation instance) for the user’s identity.
Which actually gives you a way to iterate these two chains of trusts for a 3rd party Certification Authority provider or for Vereign.
In short this way you can have an upgraded x509 protocol with multiple Certification Authorities (aka sources of trust).
What drove the choices of your technology stack?
First, we decided to use a coding language close to the machine. Our options at that date were C++ or Golang, because of our previous experience with C++, we decided to use Golang as our main backend coding language.
On the other hand, as an open source company and cyber security provider we want to know what happens on our hardware – so our chosen enterprise vendor for computer hardware must support open computer architectures. Here we decided to use OpenPower based computer architecture, and more specially IBM power machines.
Have you tried any 3rd party security companies to do some penetration testing of your software?
Not yet, but I have this planned and our back end architecture and deployment model is based on the ability to provide penetration testing companies an easy way of testing our system.
Keep in mind that the cyber security level of the given system depends on how well the system is configured. Which means we can provide any kind of trust only for Vereign hosted federation instances.