I am integrating sparkle in my mac app for automatic updates of app. following this but i have problem with step 3 Segue for security concerns
EdDSA (ed25519) signatures
To prepare signing with EdDSA signatures:
First, run ./bin/generate_keys tool (from the Sparkle distribution root). This needs to be done only once. This tool will do two things: * It will generate a private key and save it in your login Keychain on your Mac. You don’t need to do anything with it, but don’t lose access to your Mac’s Keychain. If you lose it, you may not be able to issue any new updates! * It will print your public key to embed into applications. Copy that key (it’s a base64-encoded string). You can run ./bin/generate_keys again to see your public key at any time.
Add your public key to your app’s Info.plist as a SUPublicEDKey property.
I have few questions on this implementation
1.what if i lost in future the Private key which is stored in keychain
2.can we store this private anywhere else to be safe
What are the all best practices that i can follow to be safe. Any experts with detailed explanation would be appreciated.
I have tried to export the private but there is no option this is private key stored in key chain . these are the options that i am getting when trying to export.
Any Suggestions ?
Thanks in Advance !!
Related
Currently working on a python project, and am trying to get it usable enough to the point where I could share it with other people on platforms like reddit or github. However, I can't go sharing around the API. Is there any way to include the API key but hide it somehow so it is simultaneously usable and still hidden from any users who download my repository?
There is not a way to have an API key be shared so it's both usable and private. If you can't share the API, then you'll just have to keep it to yourself.
I am writing a mac app. I want to know how to save a product key is a relatively safe and reasonable way.
For example, the way to restore Microsoft Office product key(I do not know it). Keychain maybe safe, but it is easy to find on mac.Which has a good solution?
NET supports public key encryption in various ways, such as http://msdn.microsoft.com/en-us/library/ms867080.aspx. Having said this, all you'd gain is some confidence that someone with full access to the released code would not have the ability to issue their own product keys. None of this stops them from patching the client to accept anything as a valid key. That's where obfuscation fits in.
From Encryption Product Keys : Public and Private key encryption
I need to hide a password to connect with a server. The problem is that the password is given by the service providers, so it is static.
I already thought of using the keychain, but the problem is that even if I use this I need to hard code the password to insert it in the keychain somewhere in the code.
So, is there a way to hide a static password to be available for my app, avoiding to write it in my code?
I would think about setting up a middle layer server - kind of a proxy - between users of your app and the service provider. It will allow you to:
set different password for each user
optionally give users a chance to change a password
have more control over who uses the service and what data is transmitted
be more independent of your service provider (e.g. change it anytime)
It will require more effort but may be it is more advantageous in long run.
This is not a solvable problem, and has been discussed at length around SO. For one "hub" question that includes links to several others, see Secure https encryption for iPhone app to webpage.
Using obscurity is not a horrible thing. But keep it simple. XOR the value with some random key. Done. Putting more and more layers buy you nothing, and cost you complexity (which means time and bugs, which are the enemies of both profit and security). If someone puts a debugger on your code, they're just going to log all the data you send to the server, so all the hoops you jump through to hide how you compute the password won't matter, because eventually you have to send it to the server. So keep it simple to stop people from just using "strings" to pull it out, and recognize that you cannot stop a debugger.
The only way to secure the service-provider's key is to put that key on your server, and then proxy for the service after authenticating the user. If you put it in the code, then it is discoverable, period. If this were a solvable problem, there would be no unlicensed copies of software, no unlicensed copies of music, no jailbreaks for iPhones, etc etc etc. If Apple can't stop reverse engineering when controlling every piece of the system from the hardware to the OS, you're not going to fix it inside of an app.
What you should be thinking about is how to recover if and when the key is lost. How do you discover that it's happened? How do you expire that key and create a new one? If you're shipping the key in the code, you must assume that it eventually will be discovered, and you should have a plan for dealing with it.
As a side note, one technique I've used in the past is to download the key from our server on-demand rather than encoding it anywhere in the app. We use authenticated HTTPS and check our certificates. Of course it is still possible to fool this system (it's always possible to fool a system that gives a client information they're only supposed to use a certain way), but the thinking is at least we can change the key more easily this way to stem the tide briefly if the key leaks.
This is the key and the box problem, you can keep putting your key in a new box every time and hide this key in a new box and you can keep on doing this.... but in the end you always have the last key... and nowhere to hide it.
Personally i would obfuscate the key to the keychain, and hide the real key in the keychain.
If it is a realy important secret you can use AES to encrypt your key, but then again your stuck with your encryption key, here you can use something that is device specific instead of a hardcoded value and generate your key out of that property.
For sure not perfect but will do the job in most cases.
I'm trying to find a way to verify the signing certificate of a binary in code. For example, if you run the command: "codesign -vvvvd /YourApp/Executable" you may receive the output: "Authority: Apple Root CA" etc. I'm looking for a way to do this in code. Any push or nudge in the right direction would be outstanding.
Thanks!
On the Mac, SecStaticCode and SecCode provide code signing and verification functionality. Specifically, SecCodeCopySelf() and SecCodeCheckValidityWithErrors() would be used to check the code signing of the current application.
Note that an application that has been modified and resigned (with the same certificate or any other) is effectively impossible to detect, since anyone capable of modifying the application and resigning it can stub out or otherwise defeat your verification code. The functions named above are, at best, a keep-honest-people-honest solution.
On iOS, Apple's official position is that you shouldn't attempt to do jailbreak detection or similar, and should trust the OS to get it right. Since you cannot run dynamically loaded code or read the binary data of other applications, it is not very useful to be able to verify code signing on that platform. (Whether or not Apple's official position is useful to you is another discussion entirely.)
this is possible with an OS X application using Code Signing Services or Ole Begemann's code, but doesn't appear to be possible with iOS.
I know that there are some restricted api's or code that are not allowed to be in your app when you submit it to the app store.
How do you know what they are? Is there a way to check your app before you submit it to ensure you have not used such api's?
It is probably better to avoid this problem at the design stage, than trying to fix it later, so I was wondering if there is any tool in Xcode, or document to determine this.
The way Apple intends for you to do this is to use XCode's Validation feature. When you're submitting an app, you build for achiving (or Archive from the XCode menu). Then, you open up Organizer to see the archive you just created. At this point, you can press the Validate button in Organizer. That will perform a validation, without actually submitting the app. It will tell you if you're using Private APIs. Depending on how you use them, it might identify what the violation is:
There's definitely ways that code can fool this validation step, and "get away" with using Private APIs until the reviewer looks at the bundle. But, as far as I know, those ways would all be intentional methods of hiding Private API usage, and it sounds like you're trying to discover accidental usage.
If you fail this Validation test, then you might want to use something like AppScanner, mentioned in alan duncan's answer. But, for completeness, I wanted to make sure people knew that this Validation step is available in XCode, and checking for Private API usage is one of the things it's doing before you submit (and have to wait a few days to be told what you did wrong). Also, even if you don't use the Validate button in Organizer, but just use Submit, the tool is performing a Validation for you. The only difference is whether the bundle actually gets uploaded to iTunes Connect.
If you stick to documented interfaces as suggested above, you're fine. The only issue is with third-party libraries whose implementation may be opaque to you.
There is a Mac app called AppScanner that scans from private API usage. I have no experience with it, though.
You will get more information on Apple approval process from
App Store Review Guidelines for iOS apps (You must be a registered iOS developer for accessing this data).
iOS Human Interface Guidlines.
get the private API list.
use class-dump to process the Mach-O file, and get the processed string.
use regex to get the interface, class, or method in the string.
match the API to private API list.
then GOT it~
I opened a porject to do this, but because the reason of my company, canceled. very sorry for this.