Currently i am working on mac os x.and i want to write a driver which will encrypt a device.
As mac os x 10.7 and above encrypts a device. Similar functionality i want to achieve.
1. Is anyone know how mac os x10.7 does encryption?
2. When it uses the coreStorage functionality, exactly where the password is kept in CoreStorage volume? (Which sector of device)
3. Is there any open source site which can help me debugging the driver.
Thanks in Advance.
Filevault 2 is implemented in CoreStorage.kext. That implements a IOStorage filter service which does logical block mapping and optionally encrypts/decrypts blocks using AES-XTS.
The password isn't stored with the volume, that's kind of the point. For system volumes, the password you enter on login is used to derive a key with which the master key of the volume can be decrypted. For other volumes, you can choose to store the password in your local OS X keychain.
Libfvde is an open-source library for accessing FileVault/CoreStorage volumes. See https://github.com/libyal/libfvde
The wikipedia article on FileVault is actually pretty detailed and worth reading.
Related
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!
Thanks for reading this.
I've been searching for an easy way to upload a csv file generated in the users iPhone app to a secure storage drive.
For a research project, we are looking to ask participants to answer a couple of questions that will be compiled into a csv file.
All those files need to be uploaded anonymised to one secure storage location for further processing of the results.
I have looked into Google Drive (didn't work for iOS), Softlayer Object Storage but there doesn't seem to be an easy out of the box solution.
I have been jumping through customer support for two weeks.
In an ideal world:
CSV file created in the iPhone app
User agrees to share the file
CSV file uploaded through the iPhone app into a secure storage
Ideal solution:
HIIPA complaint or secure solution
ready wrappers for implementing in xCode
Half a day of work max
Thanks again,
Best,
Joseph
maybe this can help you:
http://blog.softlayer.com/2014/softlayer-security-questions-and-answers
"5: How is my data kept private? How can I confirm that SoftLayer can’t read my confidential data?
A: This question is common customers who deal with sensitive workloads such as HIPAA-protected documentation, employee records, case files, and so on.
SoftLayer customers are encouraged to deploy a gateway device (e.g. Vyatta appliance) on which they can configure encryption protocols. Because the gateway device is the first hop into SoftLayer’s network, it provides an encrypted tunnel to traverse the VLANs that reside on SoftLayer. When securing compute and storage resources, customers can deploy single tenant dedicated storage devices to establish isolated workloads, and they can even encrypt their hard drives from the OS level to protect data at rest. Encrypting the hard drive helps safeguard data even if SoftLayer were to replace a drive or something similar."
It seems that you will need to create your server to store your data and deploy a gateway device as well.
In another hand about object storage I did not find any information if it supports HIIPA, but as the softlayer object storage is based on Open Stack I think that if Open Stack supports HIIPA Softlayer's object storage should support it as well. Just in case here some documentation about how to work with object storage using REST:
https://sldn.softlayer.com/blog/waelriac/managing-softlayer-object-storage-through-rest-apis
Regards
We finally settled of Google Firebase iOS SDK. The Firebase Storage function is fantastic.
It was very easy to integrate and the support was excellent.
We used a file upload function to the firebase storage.
Highly recommended!
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.
The web site I'm working on currently provides an option for the user to download their data in an encrypted zip file. Standard zip file encryption is nearly worthless (so I've read), so I'm looking to replace that with something that uses AES encryption but still has a self-extracting format. There are a couple of issues with doing this, which I am sure someone has worked through before:
I don't know what platform the user is on (Mac or Windows or Linux) so I can't just make a self-extracting .exe file and assume that will work. I suppose I will need to ask. (I am already asking for a password.)
My web site is running on Linux, and I suspect that most programs that produce self-extracting encrypted .exe files expect to be run (to make the .exe) on a Windows machine. I suppose I could set up a virtual machine running Windows, and have my Linux server send that virtual machine a request (and the data) to make the .exe, but that sounds complicated.
The ZIP encryption being rubbish controversy was from a long time ago (see here). The main issue with ZIP encryption is that although it uses a 128 bit AES cypher it still requires a password from the user. Attackers have already determined how the ZIP program generates a key from the password so when a user entered password contains low entropy (i.e. a simple password) then it becomes very easy to brute force the key and open the file. If you assign a large very random password it is considered very secure.
How do I find out the storage capacity of my harddisk without using the OS functions like dir or ls?
On windows:
Win32: GetDiskFreeSpaceEx
.NET: DriveInfo
If, for whatever reason, you still don't want to use those, you can send an IOCTL message direct to the disk driver.
statfs() unix system call is your friend (link points to BSD man page as used in Mac OS X).