Category: View All

CallKit integrates VoIP services with other call-related apps on the Apple device, using the same native interface, making it easier for users as they use the same dialer for all calls.  However, it’s not plain sailing and CallKit does have its limitations.  Here’s our take on it…

The Good

CallKit provides a more typical Apple interface, which is great for the user experience and provides anonymity when receiving secure calls, particularly when in a public place, because all calls look the same.  It provides integration features with other types of incoming call, which means that Armour users are able to prioritise their secure calls over a standard call, and so avoid interruptions.

The Bad

Calls made with CallKit appear in the regular iOS call log, which used to be synced to iCloud.  The sync to iCloud may be turned off, but can you rely on users to remember to do that? Importantly, this means that meta data for secure calls also appears on the standard phone log – which is far from ideal.  To identify the incoming caller, their information would need to be in the Apple push, which may mean that it requires access to the secure contacts database, which could result in call details being stored outside of the secure database, all of which would contravene a CPA certified solution.  And, all of which could give away valuable metadata to an attacker.

CallKit provides the user with an incoming call interface on the lock screen, however, if your secure comms app is held behind a secure login, it may not initiate for the incoming call.

The Ugly

The user interface is limited to Apple’s standard phone app, which means that additional functionality (i.e. buttons for messaging, video and conferencing controls) can’t easily be displayed.  CallKit also has limited ability to deal with video calls, for example, video needs to be enabled at both ends for the call to take place (whereas Armour Mobile will allow one-way video calls, since this better fits with the security and usability requirements of our customers).

Users may require the ability to disable CallKit.

Our overall take on CallKit is that while it can cause more problems than it solves, it does solve some specific issues in specialist use cases, and for this reason we will be including CallKit in an upcoming version of Armour Mobile, so that our clients have the choice.

Don’t rely on the very IP channel that has just been hacked, because your adversaries will be monitoring it!

If (when!) your organisation succumbs to a cyber-attack, the first thing you need to think about, when assessing the situation and putting together a plan for recovery and future mitigation, is exactly how you are going to communicate.  Whether it is the IT department discussing the technicalities, or communicating with senior managers and the board to keep them abreast of events, the last thing you should do is use the very platform that has just been compromised, ie, your corporate network.

In layman’s terms, if your email has been hacked, sending an email to your friends asking for help is nonsensical – your email alerts the hackers to the fact you’ve detected their presence.  And, you can’t tell if any of the responses are genuinely from your friends or from the hackers messing with you.

It is very common when hackers have compromised a system for them to watch carefully for the responses from any IT resources that are tasked with countering their attack. Typically this includes watching and subverting any communications channels that IT may be using.  It’s not unusual for hackers to send spoof messages to try and assess just how well the IT team understands the nature of the attack, to capture new passwords or other changes to security, and prevent key messages from being delivered.

During the initial investigation phase of a cyber attack it is difficult to know what systems have been compromised, so it is best not to rely on any of them, if possible.

By protecting the communications of the IT and digital forensics team, you are blocking a very useful source of information from being intercepted or modified by the hackers. In addition, by using a secure communications platform, such as Armour Mobile, and having the secure comms hosted by a third party, you are further isolating the IT team’s comms from the potentially compromised systems that they are trying to recover.

For third party ‘blue teams’ brought in to handle such hacking situations it makes perfect sense for them to bring their own secure comms solution with them – and this is a question that you should be asking any would-be supplier when tendering for such services.

Armour is now working with a number of organisations that can provide specialist technical consultancy and cyber advisory services, from penetration testing and assurance, to incident management and response, and technical security research.

With Message Burn you get to choose how long your messages last. 

When you send a sensitive message how can you be sure that only the intended recipient sees it, and that it is not lying around on a phone somewhere for others to find at a later date?

While for the majority of chitchat on consumer-grade messaging apps it really doesn’t matter, when you are sending more sensitive, work-related communications, who sees it and what happens after that can literally be a matter of life and death in some cases (for example, a journalist in an unfriendly regime meeting an interviewee, or in the case of covert ops).

With a facility like Message Burn, users can limit the life of their sensitive data at rest.  Users can set a time for their message to dissolve, disappear or as the name implies, ‘burn’. This can be either a future date and time, or an amount of time after the message has been read by the recipient. While some other enterprise apps allow one or the other, Armour Mobile provides the flexibility of both options for the user via an intuitive interface.  The ‘burn’ time can be set for each individual message.  So, for example, a user may send several low sensitivity messages without any burn time, and then one highly sensitive message regarding, say, a meeting time/venue, or a sensitive contact name, with a very short burn time.

The burn time can be applied to messages, and their attachments (which can be pictures and/or files), for one-to-one messages and to group chats. To ensure that messages to important users aren’t accidentally sent without appropriate ‘burn’ protection, you can also define default message destruction settings for any user or group, so that accidentally pressing the send button never results in sensitive data hanging around for any longer than it should – incidentally, this meets one of the key requirements for GDPR, should that be a concern for your organisation.

Message Burn will be incorporated into Armour Mobile in the next major release.  For more details contact us now: sales@armourcomms.com

You may be aware of significant security concerns raised in the last few days regarding the “Meltdown” and “Spectre” flaws identified in a variety of processors found in PCs, smartphones, servers and other products. This is an advisory to all our customers regarding Armour’s assessment of the effect of these issues.

What’s going on?

Firstly, a brief outline of these issues:*

“Meltdown” is the name given to a side-channel attack on memory isolation that affects most Intel chips since at least 2010, as well as a few Arm cores. “Meltdown” allows a normal (user) application to read (private) kernel memory, potentially allowing the app to steal passwords, cryptographic keys, and other secrets. It is easy to exploit, but easy to patch – and workarounds to kill the vulnerability are available for Windows and Linux, and are already in macOS High Sierra, for Intel parts. There are Linux kernel patches available for the Cortex-A75.

“Spectre” affects, to varying degrees, Intel, AMD, and Arm. Depending on your CPU, “Spectre” allows normal apps to potentially steal information from other apps, the kernel, or the underlying hypervisor. “Spectre” is difficult to exploit, but also difficult to fully patch, so could pose an ongoing threat for some time.

One always needs to ask whether a theoretical vulnerability can be exploited in the real world: in this case the (multiple) teams who reported these problems have proof-of-concept exploits to demonstrate the vulnerabilities so the threat is definitely real.

Although you might initially be concerned about the vulnerabilities this introduces to your personal computer or mobile phone, the wider danger is where data from many users is processed on the same machine, as happens in almost every cloud-based system where multiple applications (often from different companies) run alongside each other, but separated within ‘virtual’ environments (or ‘containers’). These vulnerabilities could allow a malicious application to examine the private data (e.g. customer passwords or cryptographic keys) for another company’s application when present on the same physical machine.

How does this affect Armour customers?

There are three key ways these vulnerabilities need to be addressed:

• Vulnerable Devices – it’s common sense, but we recommend that all customers ensure that their individual devices (PCs, smartphones) have the latest operating system security updates – not all systems have fixes for “Meltdown” or “Spectre” yet, so keep an eye out for further updates.
• Vulnerable Servers – follow the same principle as for other devices; make sure you apply the latest operating system updates. (It is possible that patching for these vulnerabilities may have some performance impact, but this has still to be fully evaluated.)
• Virtualisation – Armour’s server components can be run in a virtual environment, which could be affected by these vulnerabilities; however, it’s important to note that the Armour security architecture already minimises any potential effects:

Customers running an on-premises Armour system have total control over how and where the Armour components are run: if there are no third-party applications or organisations running in the same virtual environments, then the Armour components can’t be attacked by these vulnerabilities.

The really sensitive data (e.g. cryptographic keys) in any Armour system are not exposed to the front-end servers (which is where an attacker might try to insert malware to exploit these vulnerabilities) because this information is stored in the ‘inner’ (more secure) servers.

* For more detail, we suggest you check your preferred, technical web site, as understanding of these issues, their effects and how to counter them, is continually evolving at this time; the formal vulnerability description is on the CERT web page under ID 584653 and MITRE vulnerabilities CVE-2017-5753 and CVE-2017-5715 (for “Spectre”) and CVE-2017-5754 (for “Meltdown”). Of course it’s obligatory for any cyber issue to be given its own web page and fancy icon, hence you could look at https://meltdownattack.com/ or https://spectreattack.com/, though these both direct you to the same joint page.