Where can I find some simple sample code for public key encryption and decryption on Mac OS X? I'm frustrated that Apple's "Certificate, Key, and Trust Services Programming Guide" shows how to do this stuff on iOS, but the needed APIs (SecKeyEncrypt, SecKeyDecrypt) are apparently not available on Mac OS X. There's probably a way to do it in "CryptoSample", but it doesn't look clear or simple, and the sample project is too old to open with the current version of Xcode.
The Security Framework APIs change rather frequently between Mac OS releases. The best approach depends on what version you target:
If your code only needs to run on 10.7 and above, you can use Security Transforms, a new high-level public API for cryptography transformations. The Security Transforms Programming Guide has useful (and simple!) example code:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecTransformPG/SecurityTransformsBasics/SecurityTransformsBasics.html
You'll want to create a transform using SecEncryptTransformCreate or SecDecryptTransformCreate, set its input using SecTransformSetAttribute and execute it with SecTransformExecute.
If you need to support Mac OS 10.6 or below, you must use the low-level and rather scary CDSA APIs. CryptoSample's cdsaEncrypt is a concise example.
https://developer.apple.com/library/archive/samplecode/CryptoSample/Listings/libCdsaCrypt_libCdsaCrypt_cpp.html
You can get a CSSM_CSP_HANDLE and a CSSM_KEY from a SecKeyRef by using SecKeyGetCSPHandle and SecKeyGetCSSMKey, respectively.
To learn more about CDSA, the full specification is available from the Open Group (free, but requires registration):
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=11287
Good luck!
If the private key was created exportable, you can export it in an unprotected format and use openssl directly. This puts the raw key data directly in the address space of your application, so it defeats one of the primary purposes of the Keychain. Don't do this.
Finally, you can mess around with private functions. Mac OS 10.6 and 10.7 include, but do not publicly declare, SecKeyEncrypt and SecKeyDecrypt, with the same arguments as on iOS. The quick'n'dirty solution is to simply declare and use them (weakly linked, with the usual caveats). This is probably a bad idea to do in code that you plan to distribute to others.
There's an implementation of decrypting data using the Public-Key at: https://github.com/karstenBriksoft/CSSMPublicKeyDecrypt.
The Security.framework does not have a public API for that kind of functionality, which is why CSSM needs to be use directly even though its marked as deprecated.
To encrypt with the public key, simply use the SecEncryptTransformCreate, but for public-key decryption you need to use the CSSMPublicKeyDecrypt class.
Mac OS X contains OpenSSL in libcrypto. The CommonCrypto framework seems to be derived from SSLeay, the precursor of OpenSSL.
Related
I am trying to reduce and make as difficult as possible the ability to access my source code after being compiled by NSIS. I have read that the only way to reduce the chance of unzipping is to modify the order of the opcodes in the Source\fileform.h from the source code and then Compile the new version.
This is a bit over my head. I was wondering if anyone has done this before and willing to post one they have done. (Or create one for me?)
Main reason for this is I have info that I encrypt using blow-fish within NSIS and do not want the chance oFf someone finding out what the encryption keys are. (Used for licencing the software) I understand noting is fool proof, but just want it as difficult as possible.
I know its asking a lot, but could really this.
Thanks!
I don't believe there are any publicly available modified builds like that. And if there were and it got popular, the decompilers would just add support for it.
I have a complete step-by-step guide to building NSIS here.
If you know C/C++, Delphi or C# you could build your own private NSIS plug-in that handles the encryption details.
No matter what you do, somebody who knows how to use a debugger can easily set a breakpoint on the blow-fish plug-in and view your key. The only way around that is a custom plug-in or an external application that handles the cryptography internally...
I'm a Linux user, and I have been very hesitant to use Glade to design GUIs, since the xml files it produces can easily be modified. I know it doesn't sound like a major issue, but what if it's a commercial app that you just don't want people changing?
I use Mac OS X every once in a while, and I figured out that they use files called ".nib"s for GUIs. I think they're essentially the same type used in Nextstep and Openstep (there's even a Linux app which lets you edit these files). Anyway, these files are included in the application bundle, and according to some people, are completely editable. This person claims he even successfully edited Keynote's interface.
Now, why would that be possible? Is it completely okay for the end user to change the interface? Or is it better to have the GUI directly in the compiled application code, like traditional GTK apps?
OS X nib files are one option; the other option is to do things programmatically. For android, XML files can define the GUI or program code can do it. In Windows WPF, the UI is made in XML. Firefox/Mozilla? XUL, another XML-based UI language.
Most modern GUI toolkits have either both of these options or even just defining UIs in files.
But even binaries are modifiable. With a good binary reverse engineering tool, it's wide open. The only way to be really certain is to do what Apple did with iOS, and run signed code; the entire bundle is signed by a key and can't be run if modified.
This isn't a problem for most everyone. Why do you care if the UI is modified? The underlying code isn't, so functionality can't be added or modified.
As a corollary (and a little off-topic) something that you might have a valid concern about is stuff a little more like this.
I don't really see a problem with it. If a user messes up his UI, then it's his problem. Think of it like moddable games. Users always loved them, and in the end, most games benefit from it. There is usually nothing secret about an application's user interface. If there is, you could always do some sort of encryption.
As others have said, you can also add checksums if you just want to disallow editing.
The xml specifies little more than what the interface looks like. Without the compiled-in event handling code, it's pretty much useless. My opinion is customers change it at their own risk, and you might actually get some free useful improvements out of their hacks.
If you're really paranoid about people changing it, you could always add an MD5 digest verification step or something when you load the xml, or compile the xml string into a header file, but that defeats many of the benefits.
The theming engine can make substantial-looking changes to your GUI, as can tools like Parasite. Updating the Glade layout — at their own risk — is much safer than either of those.
What's wrong with users customizing the UI anyway?
I am asked to add a new algorithm to ssh so data is ciphered in new algorithm, any idea how to add new algorithm to ssh ?
thanks
It is possible to add some new algorithm to SSH communication, and this is done from time to time (eg. AES was added later). But the question is that you need to modify both client and server so that they both support this algorithm, otherwise it makes no sense.
I assume that you were asked to add some custom, either home-made or non-standard algorithm. So first thing I'd like to do is to warn you that the added algorithm can be weak. You need to perform at least basic search for information about this algorithm, as if it's broken, you will do completely useless and even dangerous work.
As for software modification themselves - it's a rare job to do so most likely you won't find anybody with this experience there. However the code that handles various algorithms is typical and adding new algorithm is trivial - you add one source file with algorithm implementation and then modify a bunch of places by adding one more case to switch statement.
In my career I've worked on a private fork of ssh that was sold as closed-source commercial software. Even they in all their crazy stupidity (private fork? who in their right mind uses non-Open Source encryption software? I thought our customers were completely off their rockers.) didn't add a new encryption algorithm.
It can be done though. Adding the hooks to the ssh protocol to support it isn't hard. The protocol is designed to be extensible in that way. At the beginning the client and server exchange lists of encryption algorithms they're willing to use.
This means, of course, that only a modified client and modified server will talk to eachother.
The real difficulty is OpenSSL. ssh does not use TLS/SSL, but it does use the OpenSSL encryption library. You would have to add the new algorithm to that library, and that library is a terrible beast.
Though, I suppose you could add the algorithm without adding it to OpenSSL. That might be tricky though since I think openssh may rely heavily on the way the OpenSSL APIs work. And part of how they work allows you to pass around a constant representing which algorithm you want to use and then a standard set of calls for encryption and decryption that use the constant to decide on the algorithm.
Again though, if I recall correctly, OpenSSL has an API specifically for adding new algorithms to its suite. So that may not be so hard. You will have to make sure this happens when the OpenSSL library is being initialized.
Anyway, this is a fairly vague answer, but maybe it will point you in the right direction. You should make whoever is doing this pay enormous sums of money. Stupidity that requires this level of knowledge to pull off should never come cheaply.
As I said in some questions today I´m looking for the way to get window or windowPart references at a certain location. Although I know I could use Cocoa for this purpose (I don´t know how to do it yet) I prefer (and probably need) to do this using Carbon because the entire application that needs this functionality is written in C++ but I´ve found many problems trying it.
Does anyone get a valid windowPtr or windowRef using one of the following functions? FindWindow, MacFindWindow, HIWindowFindAtLocation or FindWindowOfClass
I always get 0 as the windowRef or windowPtr that I´m looking for. What I´m doing wrong? Any ideas?
It´s true that now if you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface because some APIs commonly used by Carbon applications are not available in 64-bit applications?
Thank you.
JxXx
Based on your response to this question it appears that you are trying to get a WindowRef to another application's window.
As this posting to the carbon-dev list says:
You can't access memory in other programs. A WindowRef from another program
would be meaningless in your program's memory space.
And the word on 64-bit carbon is this:
If you want to create a 64-bit
application for Mac OS X, you need to
use Cocoa to implement its user
interface.
EDIT -
You can get the mouse location with [NSEvent mouseLocation] (Cocoa) or GetMouse() (Carbon). If you want to interact with windows belonging to another application, you'll need to use something like the Accessibility API (Cocoa), or the low-level Quartz Window list functions. The Quartz function returns a list of all windows (belonging to all applications) and limited information about each (bounds, owning PID, etc.)
I need to write a small program that can detect that it has been changed. Please give me a suggestion!
Thank you.
The short answer is to create a hash or key of the program and have the program encrypt and store that key within itself. From time to time the program would make a checksum of itself and compare it against that hash/key. If there is a difference then handle it accordingly.
There are lots and lots of ways to go about this. There are lots of very smart engineers out there that know how to work around it if that is what you are trying to avoid.
The simplest way would be to use a hash function to generate a short code which is a digest of the whole program and then check this.
It would be fairly easy to debug the code and replace the hash value to subvert this.
A better way would be to generate a digital signature using your private key and with the public key in the program to check it.
This would then require changing the public key and the hash as well as understanding the program, or changing the program code itself to subvert the check.
All you can do in the case described so far is make it more difficult to subvert but it will be possible with a certain amount of effort. I'd suggest looking into cryptographic techniques and copy protection for more information to suit your specific case.
Do you mean that program 'foo' should be able to tell if some part of it was modified prior to / during run time? That's not the responsibility of the program, its the responsibility of the security hooks in the target OS.
For instance, if the installed and trusted 'foo' has signature "xyz1234" , the kernel should refuse to run a modified (or completely new) 'foo'. The same goes for 'foo' while its currently running in memory. Look up 'Trusted Path Of Execution', aka TPE to start.
A better question to ask would be how to sign your released version of 'foo', which depends upon your target platform.
try searching for "code signing"
The easiest way would be for the program to detect its own md5 and store that in a separate file, but this isn't totally secure. An MD5 + CRC might work slightly better.
Or as others here have suggested, a sha1, sha2 or sha3 which are much more secure than md5 currently.
I'd ask an external tool to do the check. This problem reminds me of the challenge to write a program that prints itself. In Bash you could do something like this:
#!/bin/bash
cat $0
which really asks for an external tool to do the job. It's kind of solving the problem by getting away from solving the problem...
The best option is going to be code signing -- either using a tool supplied by your local friendly OS (For example, If you're targeting Windows, you probably want to take a look at Authenticode where the Operating System handles the tampering), or by rolling your own option storing MD5 hashes and comparing
It is important to remember that bets are off if someone injects a thread into your process (to potentially kill your ongoing checks, etc.), or if they tamper with your compiled application to bypass said checks.
An alternative way which wasn't mentioned is to use a binary packer such as UPX.
If the binary gets changed on the disk then the unpacking code is likely to fail.
This however doesn't protect you if someone changes the binary while it is in memory.