Secure Devices From Phishing

About

KeyTalk is a software application which can “Secure Data in Motion” in an Internet, IoT, and M2M environment.  It’s unique and innovative technology provides the next generation in private Public Key Infrastructure (PKI), and brings the advantages of X.509 certificates without creating the inherent downside of  a costly and unwieldly administration overhead.  KeyTalk’s patented certificate distribution algorithms mitigate “Phishing”, “Spear Phishing” and “Man-in-the-Middle” intrusions. In addition ,they provide the world’s first true short lived (1 second up to several days) certificate technology, for small up to those larger networks consisting of hundreds of millions of users, devices and servers. By using short lived certificates combined with your authentication and KeyTalk device recognition, it enables the highest secure communication between device/server and your network. This enables the implementation of Enterprise Single Sign-On, to simplify user operations whilst enforcing strong security. Originally a development of British Intelligence at GCHQ PKI remained “secret” until the mid-1990s. In this original iteration the public key infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. The PKI was designed to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. PKI is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred. To this day PKI remains the most secure communication method of communication and has never been successfully hacked to this day. The downside of PKI is that it imposes a significant and accumulating customer burden which requires ever increasing administration with the re-issue of certificates, problems from revocation and BYOD users unable to install the software, whilst software server updates generate a major work load. The necessity to purchase certificates creates a cost burden and though a number of software manufacturers have attempted to lighten the burden PKI has not achieved the greatest success. All installations get bogged down in the administration of PKI. The largest PKI implementation to date is the Defense Information Systems Agency (DISA) PKI infrastructure for the Common Access Cards program. KeyTalk addresses the downsides of classic PKI implementations by taking the innovative approach of offering short-lived certificates for closed user (device) and server group communities, as well as offering a secure automated distribution and (de)installation of client & server X.509 certificates. Introducing certificates with a life span shorter than the need to update revocation pointers (CRL & OCSP), it takes away the need for revocation pointers, alleviating your IT department from the burden of certificate administration. I.e your issued certificates might be valid for anything ranging from a few seconds up to a day validity, or even 1 month if your policy allows for it. One of the primary pillars in a PKI is your Registration Authority. By connecting your existing authorative IAM system(s), such as Active Directory or RADIUS based tokens, to your PKI system, you can easily automate the Registration Authority without a need to replicate your IAM data. That leaves us with the much needed positive end-user experience. PKI and positive end-user experience tend not to work well together. Requesting and installing certificates is a burden. Trusting a Root and sub-CA raise more questions than it should when burdening your end-users with this. KeyTalk goes beyond PKI by requiring a small app or SDK which deals with all the certificate enrolment aspects, making the process automated and seamless. 1) The KeyTalk client/SDK triggers the authentication to obtain a certificate in a secure manner to the KeyTalk (virtual)appliance 2) The KeyTalk appliance verifies the authentication credentials against the customer’s authorative source 3) The authorative source approves (or disapproves) the authentication 4) KeyTalk verifies the hardware fingerprint of the device and creates the certificate and key-pair 5) From the KeyTalk (virtual) appliance the certificate and key-pair are sent securely to the client device, such as the IP-camera or smartphone/laptop 6) KeyTalk’s client/SDK installs the obtained certificate and key-pair, and de-installs the old one. 7) The connection from the device to the target server environment is secured during initial handshake or when renegotiating the handshake using a proper X.509 certificate and unique key-pair. As long as you do not need data-at-rest encryption, then automated short lived certificate life cycle management will alleviate your IT department and compliance officer PKI burdens, by going beyond PKI. Innovation: patented certificate request and distribution There is a reason why nowadays CSPs offer to create a Certificate Signing Request for you: Creating a Certificate Signing Request (CSR) isn’t easy or intuitive. Not to mention that Internet of Things devices are even often incapable of creating a CSR. KeyTalk patented in 2006 its secure method to create server side a CSR, and use a secure channel over non-secure network connections, such as the Internet, to deliver the resulting X.509 certificate with corresponding strong encryption key-pair to a target device. The result is an un-surpassing easy to use method to deliver X.509 certificates including key-pairs anytime, anywhere for any validity lifetime over default port 80 to prevent potential firewall issues. More importantly its secure due to using encryption in HTTP encapsulation. In depth: Registration Authority In PKI an RA is required. Without it you wouldn’t be able to sufficiently verify if a request of a certificate is valid for the right device/server/user by a valid requesting source. When a company already trusts their authorative IAM system(s) for access to sensitive corporate information, it is logical and better practise to re-use your IAM system(s)? It’s after all already properly managed and always up to date.  KeyTalk’s PKI engine connects securely to your existing IAM system(s) such as: Microsoft Active Directory, LDAP, RADIUS, MySQL etc. With several IAM systems no longer being in the central network, and compliance requiring inter-network traffic being encrypted, the connection from KeyTalk to your IAM is of course secured, using defacto standards. Active Directory and LDAP is for example secured using LDAPS and RADIUS based connections use EAP to ensure proper data encryption. This is achieved ensuring that data doesn’t need to be replicated, the Admin doesn’t introduce yet another to be managed data-source. How does KeyTalk do that? We do a live lookup using for example a BIND. Since your IAM is always up to date, KeyTalk immediately addresses one of the biggest problems in Classic PKI: Keeping the credentials in the issued certificate up to date. How? When a short-lived certificate request has been positively authenticated based on verified received authentication credentials, these same credentials are used to query for example the Active Directory attributes. These attributes can be mapped to any X.509 certificate field, overwriting default settings, making it part of the KeyTalk generated CSR. This includes certificate lifetime, Subject Alternative Name values and (extended) Key Usage. Should KeyTalk not offer a native connector to your IAM system(s), we offer a backend API allowing you to define your own, or ask us through our partners to develop and integrate a connector based on your specifications Beyond your Registration Authority, adding Multi Factor Authentication Phishing is a problem. Passwords are no longer sufficient to protect accounts. This is why rightfully 2 Factor and Multi Factor are a necessity. One Time Password generators from various leading brands and many profiled startups, are bringing this 2FA/MFA functionality based on any of the Something you have/are/know, and other re-invented factors. KeyTalk integrates with these 2FA/MFA solutions, allowing your users to experience a better usability due to the fact that these tokens are only needed once or twice per day with KeyTalk issued certificates being valid for such Admin configured totally variable time periods. Furthermore the users are used to the offered authentication making the KeyTalk acceptance level very high. Most companies however, seek integrated solutions which not only work with users, but also with its servers and IoT devices. Tokens for these customers often do not suffice if only because an OTP generator can often not be used on a server or unmanned IoT device You don’t want to introduce a weak authentication link in your network eco-system. KeyTalk introduces a Strong Authentication factor on top of any IAM system you have in place. The KeyTalk factor looks at trusted device characteristics, ie device identification, whereby measured components go beyond traditional browser based meta-data. So while your MAC address might be nice to use despite being prone to spoofing, what KeyTalk offers is a choice of different components depending on the target device Operating System, such as: BIOS serial number, total memory, CPU InstanceID, OpenUDID, onboard sensor availability, SSH key, SIM card number and many more. Best of all KeyTalk doesn’t require the Admin to use all the components we make available. The Admin can mix and match, so don’t want to use MAC address? Remove it. Want the Total Memory used 2 times in the hardware identification hash calculation in the 3rd and 7th place? Configure it like that. This way not even KeyTalk as a manufacturer knows what you are using. Though Hardware Identification is offered as an added Multi Factor layer, you can even choose to use it as a Primary Factor. This is especially useful for Servers and IoT devices where you may not want to use pre-programmed static usernames and passwords. Your Certificate Authority, not ours With most CSPs you have a choice: It’s their way or do without. KeyTalk doesn’t work that way. We offer you a simple choice: Our way, or your way. Most of our customers already have a CA or even multiple copies of the CA across multiple domains. Replacing the existing CA is often a bad idea, if only because you do not want to configure your network with a new primary trust. In these cases you can set your own CA as the Root, under which the Primary and Signing CA of KeyTalk are generated on the KeyTalk appliance, or you can simply import you entire preferred CA into the KeyTalk product, whereby the root and primary CA private keys are of course kept offline. Or use our way to to easily setup your own CA using SHA2 and up to 4096 bit RSA or up to 521 bit ECC keys. Minimally a Primary and a Signing CA are directly used on KeyTalk, it’s a simple configuration which may take 5 minutes, after which KeyTalk generates the required CA-tree with sufficient entropy for the signing keys. This flexibility also allows you to take into account any key ceremony requirements which might be needed from different compliance point of views. But what if your CA should ever need to be replaced, and you’ve got this huge community that needs certificates under your new CA? With KeyTalk you create your new CA, enroll the new digitally signed KeyTalk trust configuration to the clients and the next certificate installed on the user device is under your new CA. HSM to be or not to be PKI systems are generally well protected in customer network environments. But most customers do not have the resources to invest in an HSM cluster to protect their private keys. KeyTalk does not enforce the use of an HSM. By default, we store the certificate signing key directly onto the KeyTalk server. It’s for most companies good enough since internal procedures and backup processes safeguard the access to the signing keys, allowing this choice to fit perfectly well within your compliance scope. Of course KeyTalk also caters to those companies who do have HSM’s implemented. Given the fact that KeyTalk runs on a hardened OpenBSD OS and integrates LibreSSL for its default crypto, PKCS#11 is fully supported. However not all HSM manufacturers actually supply libs to interface with their specific HSM. This is why KeyTalk comes with a secure HSM proxy based on Linux, which overcomes the lack of support by HSM manufacturers on OpenBSD Multi-tenant scalability As soon as you automatically start issuing X.509 certificates to your users and server community, scalability is a must-have, especially when you’re on average issuing 365 or more X.509 certificates per target client/server per year. Multi tenancy is also a must have, since most communities make use of multiple IAM targets and from a security perspective you may wish to server different customers or departments with different default certificate settings. Also our partners may offer KeyTalk as a Cloud service thus requiring it to be multi-tenant. Scalability is always determined by the weakest link. For example the KeyTalk cluster might be able to issue 1000 certificates per second, but if your IAM system can only process 100 requests per second, then there are other components which need to be scaled first by you or your System Integrator. The KeyTalk appliances are available physically and virtually, whereby the choice for OpenBSD as our primary OS, defines the compatibility with the Hypervisor. VMWare supports OpenBSD, whereas HyperV at the time of writing does not support OpenBSD in full. KeyTalk virtual appliances are provided free of charge, allowing you to scale indefinitely using a CARP mechanism. Whether you only cater to a 10 person sized community, or a 10 million connected car community. Since CARP on VMWare brings its own security challenges, such as a need to enable Promiscuous Mode, the KeyTalk cluster is advised to run in its own VLAN For larger automated environments whereby scaling needs to happen more dynamic, KeyTalk can make available other scalability mechanisms. These mechanism also overcome the need for Promiscuous Mode for example. Though KeyTalk supports built-in High Availability, Load Balancing still requires an external solution in order to create an Active-Active HA environment X.509 Single Sign-On: Interoperability at its best User experience is key. All known operating Systems support X.509 for secure 2-way authenticated SSL over TLS. And though plenty of Enterprise applications support the X.509 client certificate for Single Sign-On purposes, there are also plenty around who do not. Or who do, but due to the (Cloud) network setup it practically became impossible. When the market demanded a solution to overcome the limitation of target server applications not always supporting client certificates for a secure Single Sign-On experience, KeyTalk developed its Application Interoperability Layer (AIL). This AIL is a secure redundant proxy based on a Linux OS, that demands client certificates from a specific CA to connect to it over TLS. Depending on the target url/ip addressed it will terminate the TLS connection, or let it pass to the target server application. When it terminates due to the target application not supporting client certificates, it will convert the verified client certificate credentials into something the target application understands and expects. This might be a SAML token, or a username/password or something else, it all depends on the target application. It may also be used for username mapping, whereby the Common Name value in your certificate is for example your AD or RADIUS username, but the target application may expect something totally different. A secure connection is established over TLS between the AIL and the target application, whereby the user experiences Single Sign-On, making the end-user experience more pleasant. IT will benefit a user, instead of burden, despite being highly secure. Digital threat mitigation with KeyTalk, the what’s and what nots Digital threats are the talk of the day. If it isn’t about users being the target of Phishing attacks, it’s news articles about known and unknown malicious parties as well as government agencies using advanced techniques to eavesdrop on our data in-motion and infiltrate our corporate networks. One of the most commonly published about digital threats is Man-in-the-Middle (MitM). Though most 2-Factor Authentication solutions provide really good strong authentication, these still do not protects against MitM. And it doesn’t matter if you use Wifi, wired or cell-phone based connectivity. Though some very good new standards are being embraced, such as HSTS (RFC 6797), PKI is the only for sure method to prevent the full range of MitM threats to your network. Obviously as with anything related to IT security, assuming that your PKI or network, is properly configured and isn’t compromised. KeyTalk has been designed from the ground up to protect against MitM and is periodically tested by independent ethical hacker teams to prove our security claims in this regard. Other threats KeyTalk enables protection for are Phishing and anonymous Brute Force threats. For more information please refer to: https://keytalk.com/downloads/KeyTalkSecurityClaims.pdf What KeyTalk doesn’t protect against are threats such as: Man-in-the-browser, and compromised networks/client devices. TeamLogic has solutions available which address these specific threats. Compliance As it’s impossible to address all the different compliance regulation specifics that exist in today’s digital and offline world, it’s at least safe to say that given the plethora of digital security aspects that KeyTalk addresses and solves for your company, the KeyTalk product fits in any compliance issue that may live with a company. To name one specifically: The European Union Data Protection Reform which will take effect in 2016 and will be in full effect in 2017. To summarize this Data Protection Reform act, can result in fines starting at EUR 450.000 up to 2-5% of your company’s group yearly revenue in fines when privacy data is leaked and it’s likely that your network infrastructure meant to protect this privacy data wasn’t up to standard to defend against known and likely threats. Companies will need to address data leakage, especially when it comes to privacy sensitive information. This privacy information doesn’t just relate to people’s name or social security number. Recent court rulings also proved that someone’s location, such as registered by car tracking software and even your smartphones location tracking for a variety of apps, will fall under the Data Protection Reform. Hiding behind the fact that you implemented a firewall, and a token will not be enough, as most professionals agree that there are far more common things you can address with today’s available (security) technology and products. Conclusion KeyTalk addresses all kinds of problems we see companies struggle with when it comes to PKI, Strong Authentication, network Admin workload, and the balance between security and user experience. Implementation takes only days, so what’s stopping you to put an end to your customers PKI nightmare?