What security mechanisms are in place for iOS' custom keyboards?

Question

Apple has just announced iOS 8. The new version appears to be more extensible than previous versions, and one of the new possiblities is to allow developers to develop custom keyboards, different than the system's default.

Android has had this feature for quite some time. On Android, those keyboards are known as a possible security threat, most notably by acting as a keylogger.

Does iOS 8 prevent such malicious behaviour from happening? If so, what security mechanisms are in place?

Answer 1

There is also a safety feature built into the system itself, that prevents third-party keyboards to type into password fields - when you touch a password field the system will go back to the default keyboard temporarily.

By the way, I wouldn't trust Apple to verify that apps aren't malicious. A lot of apps use libraries provided by analytic providers, and while analytics by themselves are spyware, some of them are careless enough to transmit sensitive data (location, name, email) over plain HTTP and yet be accepted just fine in the App Store.

Answer 2

It's an old issue, but there are still some valid points as of 2022 ;)

Apple, by default, does not allow third-party keyboards to initiate network connections or access parent application's shared group container [1] - all that is protected by sandbox. Access to general pasteboard is also monitored - in iOS 14 user is informed every time an application tries to access general pasteboard, and now, in iOS 16 user must explicitly allow application to access general pasteboard. As for NamedPasteboards, keyboard cannot access it as well. In other words, iOS prevents basically all ways that keyboard could use to extract data.

However, when user explicitly grants OpenAccess [1] permissions to the keyboard (by clicking "Allow" in "Allow full access to (...) keyboard") TCC creates exceptions for networking, shared group container and named pasteboards - so now a malicious third party keyboard might be able to threaten user's privacy and security [2].

The main reason why most people might want to grant OpenAccess permission to third-party keyboard at all, is that it is basically the first thing any custom keyboard extensions will ask - without it there are no custom skins, no prediction, no nothing - which makes a custom keyboard "unattractive" and basically the same as default system keyboard.

1. https://developer.apple.com/documentation/uikit/keyboards_and_input/creating_a_custom_keyboard/configuring_open_access_for_a_custom_keyboard
2. https://www.securing.pl/en/third-party-iphone-keyboards-vs-your-ios-application-security/

Answer 3

Yes, these apps could record what you're typing, or generate arbitrary input events in your stead. There is hardly a thing you can do to prevent input-providing processes from abusing their privileges.

This being said, there are some structural factors about how input is handled on mobile UIs that limit the risks of custom keyboards (as opposed to desktops):

• Keyboard input is only used for in-app input, and not for interacting with the system's UI, switching between apps or launching apps: this makes some attacks impossible such as opening a terminal/app, typing in custom stuff and closing the app behind
• Keyboard input apps probably don't require an internet connection or statefulness beyond an API imposed by the OS, making it harder for them to act maliciously. There could still be apps that legitimately use an Internet connection (e.g. sync'ing your custom words across devices) or IPC (reading your emails to predict words you use often). As such, the best way to handle custom input providers is to give them a specific permission to handle input rather than run them unsandboxed. That is what iOS does apparently.
• According to Andre (I didn't check myself :-) ), password input fields are always managed by your native keyboard. Whether that's always a good thing is up for debate -- for instance, mobile users choose notoriously weaker passwords in order to reduce the number of mode changes they need to perform when typing a password, and keyboards with better or more customisable handling of special characters could be used to type stronger passwords on mobile UIs with little extra cost.

Answer 4

I believe the answer is quite simple unlike android, apple does not have multiple app stores and the official app store has relatively strict policies regarding app verification

in other words, even though iOS 8 allows custom keyboards, they still need to be verified before they are put up on the app store. however this is not the case for unofficial app stores and jail-broken device are (as always) at a risk

app/plugin verification aside, in a relatively closed operating system like iOS, it is not so difficult to deny apps/plugins internet access, therefore rendering a keylogger mainly useless.