I have some cryptography code that has multiple implementations, selecting which implementation at runtime based on the features of the CPU it is running on. Porting this has been straightforward so far, with Windows, Linux and Android being easy.
But in iOS it does not seem easy. While x86 CPUs have the cpuid instruction to detect features, even from user mode, the ARM equivalent is privileged. It is not possible to detect CPU features on ARM without OS cooperation.
In Windows, IsProcessorFeaturePresent works for detecting ARM CPU features. On Linux, /proc/cpuinfo is the way to go. Android has a cpufeatures library (and /proc/cpuinfo still works anyway). Mac OS has sysctlbyname with hw.optional.*.
But what about iOS? The iOS kernel has hw.optional.* like Mac OS, but it is locked down in iOS 10. (Thus, my question is not a duplicate of this one, as circumstances have since changed.) Also, getting a list of those seems difficult - Apple's open source web site runs an automated process to scrub all ARM-specific code from the OS source they give out publicly in order to make jailbreakers work harder.
You may take a look on the iOS Security Guide for business
Apparently, if you can get the CPU series name, you may also deduce which cryptographic component and how it works from the documentation.
You may note that some devices have a Security Enclave:
The Secure Enclave is a coprocessor fabricated in the Apple T1, Apple
S2, Apple S3, Apple A7, or later A-series processors.
Page 6
And you may deduce that any older CPU version has not.
Every iOS device has a dedicated AES-256 crypto engine built into the
DMA path between the flash storage and main system memory
[...]
On T1, S2, S3, and A9 or later A-series processors, each Secure Enclave
generates its own UID (Unique ID).
Page 12
Method to access cryptographic components will depend of which kind of data or storage you would to get an access ( local data storage / sync / home data / app / siri / icloud / secure note / keybag / payment / applepay / vpn / wifi password / SSO / airdrop / etc...)
Could you precise which part of the cryptographic part you need to access in your use case?
You may also take a look here and here to get additional information relative to iOS native security and cryptography API.
The reason behind iOS blocking certain hardware information is very simple. Please read about Apple A11 processor. There is so much stuff in it, also stuff, which will never be documented.
Apple simply does not want developers to be aware of it and use it. I would not expect any progress on this topic.
The only way forward at this moment is to bypass the OS and talk directly to the hardware. You would be amazed what is inside and how quickly it responds!
Related
I'm deciding between the MiniPCIe and USB accelerators for a home Linux CCTV project. The host has both USB3 and a MiniPCIe socket. The host's physical environment will range from an ambient 20C up to a potential 35C (during the summer).
I'm struggling to determine the pros and cons for each. I have gotten this far, although many are guesses:
USB:
Supports Windows and MacOS as well as Linux
Appears to have greater mindshare/use/community support on the Internet
External so can be placed to optimise heat dissipation
Heatsink
Two manual performance modes, highest requires ambient temp of max 25C
Can use up to 4.5W (900mA # 5V)
Mini PCie:
Cheaper (25%)
Lower power consumption (1.4W for 416 fps)
Automatic thermal throttling via driver
Relies on host system for active cooling
Will maintain max operation at 85C
There's probably many I've missed. In particular I can't determine if there's any limitations on throughput/capacity using USB vs PCIe. If there is no difference, then I suspect the USB form factor is the better option, if only for the mindshare, although the power usage/heat generated may be a concern.
To whittle this down to an actual question: in what cases would the Mini PCIe interace be a preferred option to the USB one?
If you are looking for a plug&play solution, then I definitely suggest the USB Accelerator. Overall, as long as you have the system requirements then it'll always works (maybe with some modifications to the standard linux configs like adding your user to the plugdev group, ...). Then the software for the CCTV is all up to you :)
PCIes sometimes need extra works like adding extra kernel arguments and modules to keep the pcie modules happy. If you are looking to launch a huge product where volumes are expected, then it is worth investigating it since it's cheaper and more compact. However, the power usage is a must for consideration as the USB Accelerator could uses up to 900mA, so that could play a factor.
May I know what host are you trying to attach the accelerators to?
Is there a way to load an existing application into an Intel SGX enclave directly?
While hmofrad is right with the statement that SGX is not designed to run an entire existing application, there are approaches to achieve exactly this: There is SCONE (closed source) and Graphene (open source). So you could read up on Graphene with SGX and check if this fits your need.
Intel SGX is designed for securing data and not loading the entire application. You can perform secure computations inside the SGX enclaves on your data by sending temporary buffers from the user space program (app.cpp) to your SGX enclave (Enclave.cpp). But why?
The enclave size is small and you can't load all your data inside it at the same time.
Inside enclaves, you're limited to a set of programming primitives like if-then-else, for-loop, and etc. Also, you can't have syscalls like open for opening a file.
Thus, if your application is large or contains some syscalls or even some forbidden standard C library functions by SGX implementation, it is impossible to import it entirely inside an enclave. But, if your application is doing some primitive operations without the need for any special syscall or function call, you can freely port it inside an enclave. Still, you can't directly load it inside an enclave you have to change your implementation to make it as a trusted enclave call inside the Enclave.cpp.
As an example, I've implemented a set of cryptographic operations e.g. SHA-2, HMAC SHA-2, AES, and etc. inside an enclave. I send/receive temporary buffers of pliantext/ciphertext data to/from enclave performing the encryption/decryption operations inside the enclave and storing the results of computation like a hash digest, or ciphertexts in userspace. In this way, I ensure that no one can tamper the results of operations because they're running inside the enclave which is secured by CPU instructions.
You can read more about this example here and check the implementation here.
As pointed out by previous answers, the Intel SGX default design does not permit to run ummodified applications in general, because the latter contain (most probably) routines which are unsupported (all syscalls) by the trusted libc provided by the Intel SGX SDK. Tools such as Scone, Graphene SGX, Haven, or SGX-LKL allow to run unmodified applications in Intel SGX enclaves.
Most of the above mentioned tools run mini-OSs inside the enclave to handle (via emulation) the unsupported syscalls. This leads to a large enclave size which is very detrimental for applications which require large memory resources; the enclave memory is limited to 128MB (or 256MB in more recent SGX versions).
The solution you choose to use will depend largely on the application you are trying to run. If the latter is not that large, you could try porting it to Intel SGX. Porting involves separating your application into trusted and untrusted parts. Only the trusted part will run in the enclave, and may communicate securely with the untrusted part (a helper) out of the enclave runtime. During porting you may still have trusted code which depends on unsupported routines like syscalls. You could solve this problem by implementing/extending your own trusted libc (just the syscalls you need) in the enclave which redefines the syscalls as wrappers to ocalls which then invoke the real routines (securely) out of the enclave; good example here. This approach however is not for newbies though. This way you will maximize enclave memory and prevent bloating it will a full-blown library OS.
On the other hand, if you are dealing with a very complex application where porting is not feasible, then I will advice you to go for a solution such as Graphene-SGX which is opensource and well documented.
I want to create a network intrusion detection system for iOS application. The main function is to allow the user to select a home network (maybe prompt them to simply enter the IP address only) and to be able to monitor the packets and if there is anything suspicious- we need to alert user via push notification or email. i wanted to use the features and functions of Snort, an open source network intrusion detection system.
Any Suggestions,Sample code ?! Where to start?
VM's do not have native hardware access, which is necessary for monitor mode. Maybe IOMMU PCI passthrough or bridged devices might work. It is probable that it is possible to compile the iOS kernel with a module that works for the wireless nic. I don't think it's a proprietary chip specific to apple, because a chip with multie technology capabilities in RF wouldn't be cost effective qt all. I'm just not sure if the filesystem blocks access in the OS framework or whatever. I have tried to compile linux/iOS ARM packages natively in the shell with the aircrack-ng source, but have not had any luck. Maybe someone would have better luck actually cross-compiling a package and sideloading it somehow.
I don't think this is possible for multiple reasons:
You wouldn't be able to compile snort for iOS.
In order to run snort you have to have the interface (NIC) in promiscuous mode, which I really don't think you can do on an iOS device (iPhone, iPad, etc) but I have never really looked into it, but Apple probably locks this down and restricts this for security purposes so if you could do it you'd likely have to jail-break the device first. It's not even possible to put the wifi card in an Apple laptop into monitor mode, which is similar.
There are a lot of dependencies for snort, most importantly the DAQ. You would probably only be able to monitor the wifi interface (even this might not be possible), not the interface used for the cellular network as this is probably a different daq than standard Ethernet nics.
This very likely is not possible on iOS, if it is it would be VERY difficult to pull off and even if you did the use case isn't really good. Even if you could get a daq for the cellular card, I don't know if promiscuous mode even exists and if it did all of the traffic on the cellular network is encrypted, so inspecting this with snort would be pointless. If you could do it for the wifi traffic it's probably not worth the effort honestly, especially since almost all traffic nowadays is encrypted, you'd have to decrypt it first, which certainly isn't possible to do.
In the view of Johnjg12's comments, I am wondering about your goal. If you want to make a NIDS, you can make it OS independent, anyway. If you want to consider only HIDS that monitors packet destined to it, we don't need it to be in promiscuous mode (a comment to Johgj12's response). so, now it is something to do with Snort on iOS. I am wondering if we can do it on a VM and then turning its promiscuous mode? Having said that I came across a link: https://www.securemac.com/macosxsnort.php
What is the simplest way to get raw access to HID devices on OS X?
I've been looking through the IOKit examples, but even opening a device seems needlessly complex, involving multiple callbacks and include things from half a dozen libraries.
libusb is available for OS X, but the kernel grabs all HID devices for exclusive access, and I have been getting strange behavior while trying to use a codeless .kext to block it from associating with my device (it prevents the kernel from grabbing the device initially, but any calls to configure the device seem to cause the kernel to grab the device away from under the little python libusb script I am testing with).
Basically, I have a HID device that just streams data. I want to open it for (ideally exclusive) access, and just get the datastream.
All the examples I have found in the IOKit docs are really complex, compared to the ~8 lines it would take in libusb. There must be a simpler way that isn't a 3'rd party library.
It's worth noting that I am entirely unfamiliar with programming for OS X in any capability.
Python support would be a nice plus
Unfortunately there is no other way than using HID Manager apis. Raw access to HID devices in OS X it's not supported.
The documentation makes it clear:
HID family. Through the HID Manager, the HID family provides a device
interface for accessing a variety of devices, including joysticks and other
game devices, audio devices, non-Apple displays, and UPS (uninterruptible
power supply) devices.
Raw access through POSIX apis it's only available for storage, network and serial devices:
Using POSIX APIs
For each storage, network, and serial device the I/O Kit dynamically
creates a device file in the file system’s /dev directory when it discovers
a device and finds a driver for it, either at system startup or as part of
its ongoing matching process. If your device driver is a member of the I/O
Kit’s Storage, Network, or Serial families, then your clients can access your
driver’s services by using POSIX I/O routines.
So you can either use HID Manager apis directly or you can use libusb or (as the other answer mentions) hidapi which are nothing more than wrapper libraries over HID Manager apis. The benefit of using these libraries is that they abstract most of the low level calls thus making them easier to use.
Take a look at the hidapi mac backend
http://www.signal11.us/oss/hidapi/
https://github.com/signal11/hidapi
I'd like to see what kinds of API/framework calls are being made by an arbitrary iOS app. Is there some sort of mechanism or tool that I can use to do this?
For clarification, the term you are looking for is hooking. It can be easily be done on a Windows system.
Excerpt from Wikipedia:
ptrace is a system call found in several Unix and Unix-like operating systems.
Given the design of iOS running one app at a time, I don't believe you can do this. Plus your app will be running in a sandbox environment with each app having it's own virtual address space.