Specialists from varying fields of expertise were brought together out of the need to protect individuals from Identity Abuse. This project team called themselves KEPT®, which stands for Key Encrypted Print Technology, and set about on their mission, the KEPT mission.
At the beginning of the project we faced an enormous dilemma, how to create a secure means of identification for an individual that could not be corrupted copied, lost or stolen. All conventional systems of identity verification today rely either on a document or a plastic card, some central database and a scanner or in most cases just an inspection of the form of identity as confirmation. At every step of the process there are points of vulnerability that have been compromised historically.
After a year of research the project team had come to some conclusions, the biggest being that we had to start with a clean slate. None of the existing systems for managing identity could be used as a foundation as they were all found to be flawed.
Where to start? The answer was surprisingly simple. Start with the individual, as all other systems start with the organisation as the point of focus. We decided to assume that the organisation was already compromised. This is a good assumption as most organisation point of contact databases would contain errors both unintentional as well as intentional. So we knew that our system had to be a clean slate against which an organisation's databases could be checked and updated. By starting with the individual at the centre of our system the processes would radiate out from that point and as long as we managed the individual's information we could prevent corruption, as the point of verification (or in the case of KEPT identification) would be out of the hands of others. So our system needed to be centralised or at least in so much that it was outside the control of others.
Thus effectually making KEPT the enrolled individual's appointed identity and personal information trustee.
Remember that a trustee's only primary responsibility is to the beneficiary, in the case of KEPT the enrolled individual. All other interactions with subscribed entities while offering a very efficient identity management service, still serve primarily to protect the individual from identity abuse and privacy abuse.
Naturally we had other moments of paradigm shift along the way, like realising if our system was to be real-time we would need to do identification and not verification. At the time we were told that this was impossible and that there was no system out there that could do it. We were also told that communication networks were to slow to handle remote real-time identification. So we just designed our own technology that could do it. You see, it was not impossible, it was just that the convention at the time only called for verification not identification. No one had bothered developing an identification system yet. Keep in mind that good developers always design for tomorrow's world looking forward to what will be, not what is. I knew that communications networks and broadband would get faster, as they did. Our first tests in 2009 delivered a window of 15 seconds. Much to slow. We realised it needed to be down to less than 5 Seconds. But even there we had some innovation to add to the process to speed things up.
Security was also of great concern and we could not afford some of the commercial offerings, as they would price our solution right out the market we where aiming our solution at. So we just figured how to create our own time token package encryption, taking the the industry default time out allowance down by a factor of 6. Thus increasing the the security to about six times higher than the industry standard. We didn't end our defences there, we also applied some innovative new ways to breaks the packets of communicated data into sizes so small most systems could not even detect the packets and routing them through hundreds of alternate nodes before reassembly at the Intelligent Information Platform or IIP as we named our centralised system. The rest of the system relies upon governance and process management technically built into the enrollment process and device identification to ensure that the solution cannot be compromised or misused in any way.
What about compatibility?
We based most of our development on readily available open source technologies. This allows for a world of application possibilities, and we hope to soon open our API to third party developers so that they can design specialised applications that will rely on our identity management platform. That said the fact that our system lies like a blanket over all other systems means that it is only the points of interaction that need to be developed for any new industry or function. Those points of interaction are also kept (excuse the pun) to a bare minimum, requiring only two new fields to be added to any database to make it compatible with our system. Yes that easy! I have over simplified some of these components to our process for ease of understanding, but the resultant solution is essentially very simple yet very elegant and as such quite robust. The KEPT identity management solution passes all the stringent requirements and tests we have thrown at it. We have had industry experts pulling it apart to find flaws or vulnerabilities, but I am happy to say that they are still at it and have not yet found a flaw.
Once we started interacting with the likes of PWC and other organisations concerned with governance we found that our solution had another use. The audit trail which we had built into our system to manage authority tree interaction could also serve quite nicely to offer automatic legislative compliance and corporate governance, especially since the enactment of the PoPI legislation. The South African Protection of Personal Information act (PoPI) is strictest privacy law any where in the world to date and KEPT had a means to offer organisations automatic compliance. All we needed was a means to incorporate PKI acceptance into our ID-Key. ID-Key® is what we named the individuals identity in our system. Well we approached SAPO, who had just been mandated by government as the provider of Public Key Infrastructure (PKI) and with a demo or two and some contract signing the KEPT project was awarded a contract to dispense the South African Government PKI digital certification. That means that an ID-Key® is an accepted form of identity and signature even in a court of law within South Africa.
So where is KEPT now in the scheme of things? After exhausting all our own personal savings and those of our nearest friends and family members, we managed to complete development to the point of proof of concept. This is where the next step of finance needs to happen. KEPT was not developed within an already commercially viable organisation. We are just a group of specialists who came together to develop a solution. So KEPT now awaits a commercialisation partner to take this awesome technology to market. Without a running commercial venture most, if not all, financiers are not eager to become involved... and here in South Africa where it all took place the Government mandated organisations are also only interested in viable commercial entities with expensive corporate infrastructure or easy projects that only require a little bit of manufacturing to launch. That said the KEPT project has identified and begun interactions with large national organisations and South African government departments that desperately need this technology. They would all implement the KEPT solution tomorrow if KEPT was commercially ready. So this is where KEPT stands, ready to commercialise a system, that could become one of the most important and needed solutions of the 21 century, should the right funding and guidance reach the KEPT project.
Please do contact us if you would like to become involved or if you would just like to show your support like us on Facebook, Google+ and LinkedIn. You can also show your support by subscribing to the KEPT email list, so that we can keep you informed about KEPT going to market.