Re: licence key validation method
At 06:41 PST on 2015-01-12, Dave Fernande wrote: If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. I don’t use Aquatic Prime, but I may have had the same problem with signatures (keys) created by the Crypt::OpenSSL::RSA Perl module. Specifically, I was told that it was missing the ASN.1 header which is required by Section 9.2 of RFC 3447. In boneheaded desperation, in my Perl script, I simply prepended the appropriate 15-byte ASN.1 header onto the message digest before encrypting, and, amazingly, the Security Transform API verified the resulting signature. I've pushed to github.com my C function for validating RSA signatures with Security Transform, based on Apple’s CryptoCompatibility sample. Now features complete error checking and returns NSError. http://github.com/jerrykrinock/Functions/blob/master/SSY-RSA.h http://github.com/jerrykrinock/Functions/blob/master/SSY-RSA.m Just another way to do it :) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 13:51, Jens Alfke j...@mooseyard.com wrote: The license mechanism serves as a reminder to new users that their demo has expired, or that the copy they borrowed from their roommate hasn't been paid for yet. Precisely. I haven't commented on this frankly-OT-but-what-the-heck-I'll-talk-to-anyone-I'm-gregarious-that-kind-of-way subthread so far, but my use of licence keys has NOTHING to do with stopping piracy (good job too, given the obvious failures the big SW companies experience in their attempts at doing so). I'm implementing licence keys partly because paying customers expect them (it adds a shine of professionalism), and partly so that I can drive sales with trial modes, unlock features and so on. If someone wants to use my app without paying for it, fine. I don't really have much of a problem with that. All the apps I've done before this have been Freeware' or DonateWare anyway. That's why I've never tackled this licence key validation process before (as Allan linked to an earlier thread, I should point out I did ask this question once before, but with that app I gave up and just released it as freeware). It's just that with this app (and the next couple I've got coming through) I'd like to give people more incentive to buy. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 07:42, João Varela joaocvar...@gmail.com wrote: all I’m saying be careful how you expose your licensing code if you are going to use objective C. I take the opposite POV. If someone's going to start messing around with otool and class-dump on my app, I know they're not going to be a paying customer. Why should I waste my time with obfuscation just to provide such people with a more educational challenge? It's rather analogous to shoplifting. Stores don't put electronic tags on goods to stop the professional thieves (because professionals have the same removal tools that the counter staff have). They put them on there to: i. suggest the item is of value and worth paying for; and ii. to stop the person who 99/100 times would pay, but might just have an aberration if you make it painfully easy for them to walk out the door without doing so. Nevertheless, if they really don't want to pay for it, they're not going to pay for it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 03:59, Charles Srstka cocoa...@charlessoft.com wrote: After all, you’re going to want some sort of automatic system for generating license codes for your users, Actually, no. As I said, the licence codes are being generated via FastSpring (and that's OpenSSL). All I need is a method to validate the code the user enters. My public key is in the app (it was as a certificate, but following Uli's advice I've hard wired the pubkey into the code instead). Now, I really appreciate the offerings that have been made so far, I can't emphasize that enough, and I've got a bit of a clearer understanding as a result, but I have to say all this use OpenSSL no use LibreSSL, use Security.framework, don't use Security.framework is more or less a repetition of the advice I gleaned from working round the stackexchange etc threads; i.e., I'm none the wiser. How do I actually start writing the method that's going to check the validity of the licence key (that's the licence code I already have, that I don't need to know how to generate, and that I've included the public key for in my app)? Allan has offered the most practical advice so far, but even he says don't use OpenSSL, and that was 10 years ago... I spent all of yesterday, as it turned out, working on the logic of my 30-day trial (oh, boy did that turn out to be harder than I imagined, but fun all the same...), so I'm still to put all the advice given so far to practical use. However, here's a new question that's been raised by your suggestions: Given that my licences are being generated with OpenSSL in the FastSpring website, does that mean I HAVE TO use OpenSSL to validate them? I'm thinking the DUH answer here has to be YES, but given my lack of knowledge about this topic, I'm taking nothing for granted. I'm also kind of surprised, given how popular non-App Store distribution seems to be becoming (at least, my purely anecdotal impression is that more OS X developers are choosing to forego or at least parallel-offer their apps outside of the App Store than 12 or 24 months ago), that there isn't a drop-and-go solution to all this licensing and trial mode logic (or at least one that has been updated in the last 5 years, that is). Does everyone really work all this out from scratch, as I seem to be doing? (And when I do, rest assured I'm going to write this up for others). I'm quite happy to put the time and effort into figuring this whole thing out from scratch if that's what's required, it's just that I don't want to invent my own wobbly wheel if someone else has already figured out how to make a nice smooth ride of it (I did that with updates, only to discover Sparkle after I'd already written my own homegrown solution...). Your thoughts, as always, are greatly appreciated. Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 10:52, 2551 2551p...@gmail.com wrote: Given that my licences are being generated with OpenSSL in the FastSpring website, Didn't FastSpring have an SDK that you just drop into your app to validate their licenses? does that mean I HAVE TO use OpenSSL to validate them? I'm thinking the DUH answer here has to be YES, but given my lack of knowledge about this topic, I'm taking nothing for granted. OpenSSL is just a security library that implements several standards and algorithms. You can use any other library that implements the same standard and algorithm as you are using. I.e. Windows AFAIK has its own security library, yet can still read browser certificates that are (were?) validated using OpenSSL on Mac and other platforms. LibreSSL is essentially OpenSSL, just a fixed version, so you should just hear LibreSSL when anyone suggests using OpenSSL for anything and you'll be fine. Security.framework is what Apple recommends and supports, so sounds like a good idea. The only problem is that it is very limited. If it does what you need it to (i.e. offers whatever algorithm FastSpring use), it's probably the best choice as long as you don't plan going cross-platform anytime soon. -- Uli ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
So my guess would be that you have somewhere on the Fastspring site asked them to generate a CocoaFob key. Correct. What that string of stuff most likely is is .. some information you have supplied, like a user name or serial number or whatever fields you told FastSpring you want in your license to be Correct again. So the normal way to verify that key would be to download CocoaFob and use whatever ObJC function it has to verify keys. Yep, got that far sometime last week... Or you go find documentation on CocoaFob’s file format, Tried that... which I’m sure is available, It it were, and had I found it, or could make sense of it, I wouldn't be here. and you work out how to turn that string back into binary data, and you use your public key to ‘verify’ it by doing the reverse of what was done to generate it. BINGO! That's my question. i.e., How is this done? You mentioned earlier that CocoaFob seemed to be a little unloved. Surely if FastSpring is still supporting it... Roland, you have understood the whole thing absolutely perfectly. My problem is I can't work out the turn it back into binary data and verify it bit. However, the last quote above is perhaps the key (no pun intended). Rather than annoying you good folks, and trying to get you to reverse engineer something you're not familiar with first hand, I should really be asking FastSpring Support. It's not like I haven't considered this before; it's just that their docs (such as they are) on this all just point to 3rd party links, which are either dead (AquaticPrime) or point to stuff full of deprecations (the CocoaFob repository I cloned from their link had 38 deprecations in it , and that was AFTER I did all Xcode's automatic attempts for ARC conversion etc). Also, I figured this is a Cocoa problem not a FastSpring service problem, but I'm flat out of road to travel here without someone giving me specifics. Anyway, look guys. I appreciate the help. I'm just going to throw this at FastSpring and see what they come back with. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 6:39 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 12 Jan 2015, at 10:52, 2551 2551p...@gmail.com wrote: Given that my licences are being generated with OpenSSL in the FastSpring website, Didn't FastSpring have an SDK that you just drop into your app to validate their licenses? No, they support a couple third party solutions out of the box, or let you supply your own generator script. They were also nice enough to add a JavaScript API for me to support my own scheme since AquaticPrime and CocoaFOB didn’t work for me. Very helpful folks! does that mean I HAVE TO use OpenSSL to validate them? I'm thinking the DUH answer here has to be YES, but given my lack of knowledge about this topic, I'm taking nothing for granted. OpenSSL is just a security library that implements several standards and algorithms. You can use any other library that implements the same standard and algorithm as you are using. I.e. Windows AFAIK has its own security library, yet can still read browser certificates that are (were?) validated using OpenSSL on Mac and other platforms. If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. The verify transform does not work for the above reason; and the decrypt transform does not work either because that would require you to decrypt using the public key. Security.framework enforces cryptographic hygiene - you can only decrypt with a private key and verify a signature with a public key. LibreSSL is essentially OpenSSL, just a fixed version, so you should just hear LibreSSL when anyone suggests using OpenSSL for anything and you'll be fine. Security.framework is what Apple recommends and supports, so sounds like a good idea. The only problem is that it is very limited. If it does what you need it to (i.e. offers whatever algorithm FastSpring use), it's probably the best choice as long as you don't plan going cross-platform anytime soon. -- Uli ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 7:51 AM, 2551 2551p...@gmail.com wrote: if anyone here is using FastSpring or similar (eSellerate, Kagi) I've used eSellerate for many years. They provide a very well-documented API for generating and validating registration keys in a variety of formats for purchase in your application and/or on your website, and they handle credit card and other forms of payment and currency conversion for you. They charge a percentage fee, of course, and I have been happy to pay it for the services they provide. You have to write some code of your own to implement their API, but it isn't hard to do. I have written a small Objective-C class of my own to integrate their API into my applications, and I have only had to update it a few times in the years since. To use it in each of my applications, I make a single call into my class when my application is launched and my class's calls into the eSellerate API do the rest. -- Bill Cheeseman - b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 20:38, Bill Cheeseman wjcheese...@gmail.com wrote: I've used eSellerate for many years. They provide a very well-documented API for generating and validating registration keys in a variety of formats for purchase i Thanks for that, Bill. I'm not in any way contractually obliged to stay with FastSpring, though I've invested a lot of effort already setting up my product and store, but if their support can't put me on the right path, I may very well look at what eSellerate have to offer. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 20:37, 2551 2551p...@gmail.com wrote: On 12 Jan 2015, at 18:44, Roland King r...@rols.org wrote: Part of the problem, at least for me, is I haven’t figured out yet what you actually have that you’re trying to verify. Is it a string, a file Thanks, Roland. It's a string that looks like this: DAWFE-F1AU6-6ZBFX-4FWHE-JQN8V-SSSUQ-JY3DL-WQY4B-A9KHP-SZA5V-765MN-63Z8W-GF9H5-C6XCW-N9L7A-K and they are generated by code that starts and ends with -BEGIN DSA PRIVATE KEY -END DSA PRIVATE KEY- Does that help at all? I’m sure it all helps. I don’t know the answer here but I am trying to ask questions which might point to a solution. The code which generates it, the key you most sensibly removed the bulk of :), I’m assuming that’s not really code which generates it, it’s your private key which you uploaded in that format to the Fastspring website so they can use it to sign things. Now to the key - it looks like a registration key. Iterating quickly through the list of ‘supported types’ I find that it looks remarkably like a CocoaFob key http://cocoadev.com/CocoaFob http://cocoadev.com/CocoaFob The example on there is GAWQE-FCUGU-7Z5JE-WEVRA-PSGEQ-Y25KX-9ZJQQ-GJTQC-CUAJL-ATBR9-WV887-8KAJM-QK7DT-EZHXJ-CR99C-A So my guess would be that you have somewhere on the Fastspring site asked them to generate a CocoaFob key. There must be an option there somewhere to say what kind of key you want or it wouldn’t know. Perhaps that isn’t a CocoaFob key, but I didn’t instantly see another one which has 15 4 character sequences and a single character, but I didn’t look too hard. What that string of stuff most likely is is .. some information you have supplied, like a user name or serial number or whatever fields you told FastSpring you want in your license to be, and it’s produced a piece of binary information with those fields in it, in a defined format, and then it’s signed it with the private key you gave it to produce another binary sequence. Then that sequence has been encoded into probably Base32, possibly modified base32 So the normal way to verify that key would be to download CocoaFob and use whatever ObJC function it has to verify keys. Or you go find documentation on CocoaFob’s file format, which I’m sure is available, and you work out how to turn that string back into binary data, and you use your public key to ‘verify’ it by doing the reverse of what was done to generate it. That requires first of all understanding the format. You mentioned earlier that CocoaFob seemed to be a little unloved. Surely if FastSpring is still supporting it for current key generation then perhaps it’s not that unloved, at least the probably very small piece of it which verifies keys and gives you the information encoded in them which it appears is all you really want. Perhaps there is tons more in the framework which doesn’t matter, but I’d expect the key verification and information extraction piece should be no more than a couple of hundred lines of code which don’t change ever. So next step is to work out what you’ve actually asked Fastspring to give you. Is it CocoaFob or something else? Then decide if you want to use another format, try to resurrect the library for the format you have, or find out what the format string is, in binary, how it was encoded and thus how you can verify it. When you get to the point of being able to say ‘my license key returned by Fastspring represents the following binary information (NSData*..) and it was signed using a private key for which this .. is the public key, how can I verify that data, it may then be possible to provide a few lines of code to do that thing. It’s going to be better to use the library! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 18:44, Roland King r...@rols.org wrote: Part of the problem, at least for me, is I haven’t figured out yet what you actually have that you’re trying to verify. Is it a string, a file Thanks, Roland. It's a string that looks like this: DAWFE-F1AU6-6ZBFX-4FWHE-JQN8V-SSSUQ-JY3DL-WQY4B-A9KHP-SZA5V-765MN-63Z8W-GF9H5-C6XCW-N9L7A-K and they are generated by code that starts and ends with -BEGIN DSA PRIVATE KEY -END DSA PRIVATE KEY- Does that help at all? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 18:39, Uli Kusterer witness.of.teacht...@gmx.net wrote: Didn't FastSpring have an SDK that you just drop into your app to validate their licenses? That's actually what I expected when I signed up, but it doesn't appear to be the case, unless I've overlooked something somewhere. My understanding of their documentation is that this is very much a matter of 3rd party support. Their links to both AquaticPrime and CocoaFob are both well out of date and what little info FastSpring do offer on this is very basic (even to my limited understanding...). Of course, I could have missed something, and if anyone here is using FastSpring or similar (eSellerate, Kagi) and can confirm otherwise, I'd be both relieved and grateful to get your advice. I must admit when I started this thread, I did so in the hope that someone else on the list would be familiar with using this kind of service and be able to point me in the right direction. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 12 Jan 2015, at 17:52, 2551 2551p...@gmail.com wrote: On 12 Jan 2015, at 03:59, Charles Srstka cocoa...@charlessoft.com wrote: After all, you’re going to want some sort of automatic system for generating license codes for your users, Actually, no. As I said, the licence codes are being generated via FastSpring (and that's OpenSSL). All I need is a method to validate the code the user enters. My public key is in the app (it was as a certificate, but following Uli's advice I've hard wired the pubkey into the code instead). Now, I really appreciate the offerings that have been made so far, I can't emphasize that enough, and I've got a bit of a clearer understanding as a result, but I have to say all this use OpenSSL no use LibreSSL, use Security.framework, don't use Security.framework is more or less a repetition of the advice I gleaned from working round the stackexchange etc threads; i.e., I'm none the wiser. How do I actually start writing the method that's going to check the validity of the licence key (that's the licence code I already have, that I don't need to know how to generate, and that I've included the public key for in my app)? Allan has offered the most practical advice so far, but even he says don't use OpenSSL, and that was 10 years ago... I spent all of yesterday, as it turned out, working on the logic of my 30-day trial (oh, boy did that turn out to be harder than I imagined, but fun all the same...), so I'm still to put all the advice given so far to practical use. However, here's a new question that's been raised by your suggestions: Given that my licences are being generated with OpenSSL in the FastSpring website, does that mean I HAVE TO use OpenSSL to validate them? I'm thinking the DUH answer here has to be YES, but given my lack of knowledge about this topic, I'm taking nothing for granted. I'm also kind of surprised, given how popular non-App Store distribution seems to be becoming (at least, my purely anecdotal impression is that more OS X developers are choosing to forego or at least parallel-offer their apps outside of the App Store than 12 or 24 months ago), that there isn't a drop-and-go solution to all this licensing and trial mode logic (or at least one that has been updated in the last 5 years, that is). Does everyone really work all this out from scratch, as I seem to be doing? (And when I do, rest assured I'm going to write this up for others). I'm quite happy to put the time and effort into figuring this whole thing out from scratch if that's what's required, it's just that I don't want to invent my own wobbly wheel if someone else has already figured out how to make a nice smooth ride of it (I did that with updates, only to discover Sparkle after I'd already written my own homegrown solution...). Your thoughts, as always, are greatly appreciated. Phil Part of the problem, at least for me, is I haven’t figured out yet what you actually have that you’re trying to verify. Is it a string, a file, a binary blob of data or what? I just took a look at the Fastspring site, knowing nothing about them, and as far as I’ve been able to tell at this point they generate license keys in various formats with the expectation they will be used by code which links a library which knows that format. They mention AquaticPrime and CocoaFob and others. I’m assuming that each of those libraries defines a format, defines what ‘signing’ means and defines what data you get when something has been signed. Normally you’d link one of those, ask for your license keys to be generated in that particular format and call some few lines of code in the library to verify it. You said in your first mail that you have DSA key generation set up. I didn’t see anything on Fastspring’s website named 'DSA key generation'. I know what a DSA key is, I know how to use a DSA key to sign/verify something, that doesn’t say anything however about what data is being signed and what format you’re getting it in. No you don’t have to use OpenSSH just because they use OpenSSH. OpenSSH is just one implementation of a number of well-defined and well-known algorithms. What type of key have you asked Fastspring to generate for you? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
This is a fight you cannot win, so don't waste your time. A dedicated cracker will bypass any protection. I use minimal obfuscation and asymmetric key generation, and that's it. Gleb On 13 January 2015 at 02:32, Graham Cox graham@bigpond.com wrote: On 13 Jan 2015, at 1:18 pm, Charles Srstka cocoa...@charlessoft.com wrote: Now I just put it in plain C/Obj-C functions, because: 1. The assembly is always there. I agree about just using plain code, as the obfuscation is in the source mostly, not the resulting object code. But if it's built from macros, and then those macros are used whenever you need to check against licensed/unlicensed, then at least that forces a would-be attacker to patch every place, not just one. Chances are the work involved isn't worth the effort. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/glebd70%40gmail.com This email sent to gleb...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Monday, January 12, 2015, João Varela joaocvar...@gmail.com wrote: Hi I rolled out my own license scheme so that I don’t have to pay anyone. ;) I find that coding license checking methods with Cocoa and Objective-C is terribly unsafe. Objective-C has the nasty habit of exposing classes and their methods, which you can easily access/find out if you know what you are doing (otool and class-dump for starters). Yes, and some other languages like Java, .NET, etc have the same problem. The runtime nature of Objective-C means that information about the classes must be stored in the binary, which makes it easy for determined hackers to crack your application. I do all my license checking code in C++ or just plain C, and use redundant checking in different places. Another trick I learned in a conference is to use critical variables as static variables rather than class ivars. Another important thing to do is trying to tie in your code with other critical subroutines in your program so that if a hacker patches your binary to change its functionality, it will break other things as well. This can be tough to do but can frustrate a pirate enough to where he may abandon the cracking attempt (especially if he's a novice). That may seem obvious, but I once saw an app (I won't say which) which encoded it's licensing technology in an external, loadable bundle. Replacing that bundle could thus crack the application without even having to modify the main app. However, my needs are probably different than yours, but all I’m saying be careful how you expose your licensing code if you are going to use objective C. Separate out your license code so that it is never called from Objective-C: make it a static C method and call it via assembly if you have to. But don't do something dumb like hookup your validation code to a nib or to a view controller or app delegate - that makes it *way* too easy to find out where your validation code is stored, allowing a novice cracker to easily circumvent any protection. Please read this: http://loadcode.blogspot.pt/2006/02/cracking-software-on-os-x.html and this: http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it Both very interesting articles, but tbh, I think that those techniques are fairly simple to perform for any software developer worth his salt. By implementing common sense security you can throw off 90% of potential crackers, leaving you only with the professionals to deal with. And you can throw in little surprises for them. ;) HTH J. Varela ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com javascript:;) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com javascript:; ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 6:42 PM, João Varela joaocvar...@gmail.com wrote: Hi I rolled out my own license scheme so that I don’t have to pay anyone. ;) I find that coding license checking methods with Cocoa and Objective-C is terribly unsafe. Objective-C has the nasty habit of exposing classes and their methods, which you can easily access/find out if you know what you are doing (otool and class-dump for starters). I do all my license checking code in C++ or just plain C, and use redundant checking in different places. Another trick I learned in a conference is to use critical variables as static variables rather than class ivars. However, my needs are probably different than yours, but all I’m saying be careful how you expose your licensing code if you are going to use objective C. Please read this: http://loadcode.blogspot.pt/2006/02/cracking-software-on-os-x.html and this: http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it I used to worry about stuff like that, and spent a whole bunch of time trying to obfuscate all the licensing code. Now I just put it in plain C/Obj-C functions, because: 1. The assembly is always there. No matter how many precautions you take, it’s always going to be possible to crack your code. It’s just a matter of how much time one chooses to spend cracking it. 2. There’s *always* going to be at least one guy who’s willing to spend enough time to crack it. 3. That one guy will post his crack on a torrent somewhere, and then everyone else will have access to it regardless of their skill level. Basically, it’s a waste of time. If people want a cracked version of their app, they’ll get a cracked version of your app. Fretting about things like this is just a time sink without much benefit. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 8:32 PM, Graham Cox graham@bigpond.com wrote: On 13 Jan 2015, at 1:18 pm, Charles Srstka cocoa...@charlessoft.com wrote: Now I just put it in plain C/Obj-C functions, because: 1. The assembly is always there. I agree about just using plain code, as the obfuscation is in the source mostly, not the resulting object code. But if it's built from macros, and then those macros are used whenever you need to check against licensed/unlicensed, then at least that forces a would-be attacker to patch every place, not just one. Chances are the work involved isn't worth the effort. --Graham Also a waste of time. Once you find one instance of the thing, you can just do a search through the binary of what you found to find all the rest. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
Hi I rolled out my own license scheme so that I don’t have to pay anyone. ;) I find that coding license checking methods with Cocoa and Objective-C is terribly unsafe. Objective-C has the nasty habit of exposing classes and their methods, which you can easily access/find out if you know what you are doing (otool and class-dump for starters). I do all my license checking code in C++ or just plain C, and use redundant checking in different places. Another trick I learned in a conference is to use critical variables as static variables rather than class ivars. However, my needs are probably different than yours, but all I’m saying be careful how you expose your licensing code if you are going to use objective C. Please read this: http://loadcode.blogspot.pt/2006/02/cracking-software-on-os-x.html and this: http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it HTH J. Varela ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 1:18 pm, Charles Srstka cocoa...@charlessoft.com wrote: Now I just put it in plain C/Obj-C functions, because: 1. The assembly is always there. I agree about just using plain code, as the obfuscation is in the source mostly, not the resulting object code. But if it's built from macros, and then those macros are used whenever you need to check against licensed/unlicensed, then at least that forces a would-be attacker to patch every place, not just one. Chances are the work involved isn't worth the effort. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 00:34, Gleb Dolgich gleb...@gmail.com wrote: You can throw it at me as well, what with me being the author of CocoaFob Gleb, I appreciate your input. I found the no_openssl branch and downloaded it, but I'm still unsure what to do with it. On the CocoaFob page it says There is no framework or a library to link against. You include the files you need in your application project directly. Could you walk me through which files I need to include in my project? Presumably, I only need the stuff in the objc folder, do I import all of those files? And if so, what headers do I import into the class that contains my registration view? What method/methods do I connect the Enter button and NSTextField where the code is entered (in my licence validation window) to? This is the level of help I need. TIA Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 9:07 PM, pscott psc...@skycoast.us wrote: Experience has taught me that copy protection and license keys almost never prevent software piracy, except where the cost of ownership is so low that defeating the protection isn't worth the effort. I don't mean to discourage anyone, but no matter how clever you think your method may be there is certainly someone more clever than you. Agreed 100%. The harder you make it, the more of a tempting challenge you provide to someone. And it only takes one person to upload the crack. In those circles it's a badge of honor to be the first to crack an app, and a major way of gaining cred. The Intel version of Mac OS X was absolutely _riddled_ with integrity checks of this sort to guard against attempts to run OS X on non-Apple hardware. There were standard check macros that got inserted multiple times into nearly every binary in the OS, from the kernel through Calculator.app. Even so, it didn't take very long for people to patch all of them out and get the OS running on Hackintoshes. As the saying goes, Locks are there to keep honest people out. The license mechanism serves as a reminder to new users that their demo has expired, or that the copy they borrowed from their roommate hasn't been paid for yet. It won't stop someone who wants to get the app for free and is willing to spend five minutes hunting torrents. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
You don't need cocoafob.m as it's test code. CFobLicVerifier.{h|m} and
CFobError.{h|m} should be it as all the necessary decoding in the
no_openssl branch is handled using SecurityFramework. The function
codecheck() in cocoafob.m just shows you how to verify a licence.
Regards,
Gleb
On 13 January 2015 at 04:31, 2551 2551p...@gmail.com wrote:
On 13 Jan 2015, at 11:23, 2551 2551p...@gmail.com wrote:
Is that all I need to do?
I see I need CFobError, too. Is just this stuff going to be enough to get
this to work?
CFobError.h √
CFobError.m √
CFobLicVerifier.h √
CFobLicVerifier.m √
cocoafob.m √
Best
Phil
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/glebd70%40gmail.com
This email sent to gleb...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 11:05, 2551 2551p...@gmail.com wrote: Presumably, I only need the stuff in the objc folder, do I import all of those files? And if so, what headers do I import into the class that contains my registration view? What method/methods do I connect the Enter button and NSTextField where the code is entered (in my licence validation window) to? This is the level of help I need. OK, looking through the files, I'm guessing I need to import CFobLicVerifier.h and .m, along with cocoafob.m. I then pass my pubkey and the user's licence to the codecheck method in cocoafob.m. and handle the returning bool appropriately. Is that all I need to do? Or is there more to it? Anything else? Do I need all those other files in the objc folder? CFobError.h CFobError.m CFobLicGenerator.h CFobLicGenerator.m CFobLicVerifier.h√ CFobLicVerifier.m√ CocoaFob|Info.plist CocoaFobARC|Info.plist CocoaFobTests MyApp.scriptSuite MyApp.scriptTerminology NSData+PECrypt.h NSData+PECrypt.m NSString+PECrypt.h NSString+PECrypt.m NSString|Base64Extensions.h NSString|Base64Extensions.m URLCommand.h URLCommand.m cocoafob.1 cocoafob.m √ cocoafob.xcodeproj decoder.c decoder.h encoder.c encoder.h pxlic.m Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 11:52, Gleb Dolgich gleb...@gmail.com wrote:
You don't need cocoafob.m as it's test code. CFobLicVerifier.{h|m} and
CFobError.{h|m} should be it as all the necessary decoding in the no_openssl
branch is handled using SecurityFramework. The function codecheck() in
cocoafob.m just shows you how to verify a licence.
Right! Gotcha. I will try this when I get back from work tonight.
I may be back with more questions after that, though hopefully not! :-)
Thanks again for your input.
Best
Phil
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: licence key validation method
On 13 Jan 2015, at 11:23, 2551 2551p...@gmail.com wrote: Is that all I need to do? I see I need CFobError, too. Is just this stuff going to be enough to get this to work? CFobError.h √ CFobError.m √ CFobLicVerifier.h √ CFobLicVerifier.m √ cocoafob.m √ Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 1/12/2015 7:30 PM, Gleb Dolgich wrote: This is a fight you cannot win, so don't waste your time. A dedicated cracker will bypass any protection. I use minimal obfuscation and asymmetric key generation, and that's it. Gleb I haven't been following this thread closely, but I do wish to respond to Gleb's comment in hope that it finds relevance. Over the last 25+ years I've purchased more than $100k worth of personal software[1][2], and nothing perturbs me more than copy-protection and license keys [3]. When such things become sufficiently annoying, I spend the time to remove the annoyance. I have successfully done this with dozens of software products, regardless of the type of method used, either software or hardware (dongle) support. The two most difficult methods [4] to overcome involve encryption of run-time code when combined with compression, and a high-quality dongle with encryption when used properly [5][6]. If you aren't using either of those methods (and properly) you probably aren't going to stop piracy. Even if you do use one of those methods properly, you might stop a younger me [7] from removing the protections, but there are certainly people out there more determined [8] than me who will succeed. Experience has taught me that copy protection and license keys almost never prevent software piracy, except where the cost of ownership is so low that defeating the protection isn't worth the effort. I don't mean to discourage anyone, but no matter how clever you think your method may be there is certainly someone more clever than you. Paul [1] Yes, I am a moron, especially considering that the bulk of it was utter crap or obsolete in time units easily counted in months. [2] Including contributions to open-source projects, and individual software programmers who asked for such. [3] Please don't flame me for disliking copy protection. I understand all the reasons, but I don't have to like it. [4] Based on my experience. If there are other more effective methods, I haven't run into them. [5] Note that I have never failed; but experience has taught me where *I* would give up. [6] Fortunately for me, all the adopters of dongles that I've encountered have either used inferior products, or didn't use them properly. [7] The older me has given up; life is too short with more satisfying pleasures. [8] Determined, intelligent, or lucky. [Bonus] For those who have read this far: Many moons ago I worked as a consultant at a Savings and Loan. The special projects manager there had his staff using a 4GL software product (never mind which one) that required a key disk (floppy) be inserted to use the product. One day the manager remarked how problematic the key disk was, always getting lost, or sometimes failing to read properly. I told him it was no problem, I would remove the requirement. It took me nearly 40 hours (much longer than I had anticipated), but I succeeded, despite heavy encryption being used throughout all the modules comprising the product. A month or so later the salesman from the vendor was talking to the manager about feature requests — as luck would have it I was present — when he happened to notice that one of the staff sat down at her desk, fired up the product without the key disk and began working. The salesman stopped in mid-sentence, and remarked, I just noticed you have no key disk inserted. The special projects manager told him his people removed that requirement. The salesman was dumbfounded. All he could keep saying was, That's impossible! That's impossible! smime.p7s Description: S/MIME Cryptographic Signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 8:05 PM, 2551 2551p...@gmail.com wrote: On the CocoaFob page it says There is no framework or a library to link against. You include the files you need in your application project directly. That's pretty inadequate, IMHO (speaking as a library developer.) The project should either build a static library or framework that apps can link against, or it should have a CocoaPods configuration. It shouldn't just ask developers to sift through a big bag of unfamiliar source files and figure out how to slot them in. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
We just implemented a bunch of license code in our upcoming app and we went with CocoaFob. I updated it a bit as I don’t think its been updated in a bit, but honestly its not hard. The foundation of the code is good, so it works. Just my two cents. On Jan 12, 2015, at 7:09 AM, Roland King r...@rols.org wrote: I’m sure it all helps. I don’t know the answer here but I am trying to ask questions which might point to a solution. Alex Kac - President and Founder Web Information Solutions, Inc. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
Or you go find documentation on CocoaFob’s file format, Tried that… There is no file involved, it’s just a string containing user name and whatever else you need to verify the license. It is described in CocoaFob README and there is a small sample available as well. which I’m sure is available, It it were, and had I found it, or could make sense of it, I wouldn't be here. and you work out how to turn that string back into binary data, and you use your public key to ‘verify’ it by doing the reverse of what was done to generate it. BINGO! That's my question. i.e., How is this done?” You mentioned earlier that CocoaFob seemed to be a little unloved. Surely if FastSpring is still supporting it… I use CocoaFob in my apps and I consider it stable, so perhaps not entirely ‘unloved’ :-) Roland, you have understood the whole thing absolutely perfectly. My problem is I can't work out the turn it back into binary data and verify it bit. However, the last quote above is perhaps the key (no pun intended). Rather than annoying you good folks, and trying to get you to reverse engineer something you're not familiar with first hand, I should really be asking FastSpring Support. It's not like I haven't considered this before; it's just that their docs (such as they are) on this all just point to 3rd party links, which are either dead (AquaticPrime) or point to stuff full of deprecations (the CocoaFob repository I cloned from their link had 38 deprecations in it , and that was AFTER I did all Xcode's automatic attempts for ARC conversion etc). Also, I figured this is a Cocoa problem not a FastSpring service problem, but I'm flat out of road to travel here without someone giving me specifics. There is a `no_openssl` branch of CocoaFob which uses SecurityFramework instead of OpenSSL and shouldn’t have any deprecations. I should merge it into master at some point and abandon support for old OS X versions. The main repository is https://github.com/glebd/cocoafob Anyway, look guys. I appreciate the help. I'm just going to throw this at FastSpring and see what they come back with. You can throw it at me as well, what with me being the author of CocoaFob and all (actually, more like co-author now that quite a few people have contributed to it). I worked closely with FastSprint a few years ago to get them to support CocoaFob and so far it has been working perfectly for me and a few other people. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. The verify transform does not work for the above reason; and the decrypt transform does not work either because that would require you to decrypt using the public key. Security.framework enforces cryptographic hygiene - you can only decrypt with a private key and verify a signature with a public key. Are you sure about that? The latest version of CF based AquaticPrime on GitHub using Security.framework: https://github.com/bdrister/AquaticPrime/pull/32 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
Of course, I could have missed something, and if anyone here is using FastSpring or similar (eSellerate, Kagi) and can confirm otherwise, I'd be both relieved and grateful to get your advice. I must admit when I started this thread, I did so in the hope that someone else on the list would be familiar with using this kind of service and be able to point me in the right direction. Using FastSpring for years now. Their support and service is superb, and reasonably prices. The missing part is they don’t have license validation methods - especially not “activation” like stuff. The already mentioned DevMate service looks great and may fill the hole, but they changed their pricing method a couple of weeks ago - for me it sounds a bit overpriced: http://devmate.com/pricing http://devmate.com/pricing A relatively new runner-up is Paddle, they handle time limited trials, license activations as well: https://www.paddle.com https://www.paddle.com/ LimeLM is a licensing framework which works well with FastSpring as far I know: http://wyday.com/limelm/ http://wyday.com/limelm/ Tamas ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 12:05 PM, Jens Alfke j...@mooseyard.com wrote: Somebody (Dave Fernandes, apparently) wrote: If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. The verify transform does not work for the above reason; and the decrypt transform does not work either because that would require you to decrypt using the public key. Security.framework enforces cryptographic hygiene - you can only decrypt with a private key and verify a signature with a public key. The Security Transform API won't let you do that. But there are lower level functions in the framework (the CDSA API) that allow it. —Jens Yes, but aren’t they all deprecated? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
Somebody (Dave Fernandes, apparently) wrote: If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. The verify transform does not work for the above reason; and the decrypt transform does not work either because that would require you to decrypt using the public key. Security.framework enforces cryptographic hygiene - you can only decrypt with a private key and verify a signature with a public key. The Security Transform API won't let you do that. But there are lower level functions in the framework (the CDSA API) that allow it. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 12, 2015, at 11:53 AM, Tamas Nagy tamas.lov.n...@gmail.com wrote: If you use AquaticPrime, unfortunately, it does not generate standard signatures. It manually hashes and then encrypts using the private key. This sounds like a normal signature, but it is missing some information stored in standard PKCS #1 v2.0 signatures. This means that Security.framework WILL NOT be able to verify an AquaticPrime signature. The verify transform does not work for the above reason; and the decrypt transform does not work either because that would require you to decrypt using the public key. Security.framework enforces cryptographic hygiene - you can only decrypt with a private key and verify a signature with a public key. Are you sure about that? The latest version of CF based AquaticPrime on GitHub using Security.framework: https://github.com/bdrister/AquaticPrime/pull/32 Interesting. I haven’t checked in a while. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 10, 2015, at 10:34 PM, 2551 2551p...@gmail.com wrote: Yes, that's precisely what I'm looking for and don't seem able to find. Can anyone suggest one? I've been all over stackexchange etc, and there seems to be a lot of confusion out there (or, rather, the more I read, the more confused I'm getting). I feel your pain. The crypto APIs are IMHO the worst designed APIs in OS X / iOS. (They're not even compatible between the two OSs; each one has annoying incomplete areas.) Apple has code samples called CryptoCompatibility and CryptoSample (the latter one doesn't seem to be in Xcode anymore but you can find it online) that show how to perform some basic tasks with the APIs, including signatures. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 11, 2015, at 2:05 PM, Jens Alfke j...@mooseyard.com wrote: On Jan 10, 2015, at 10:34 PM, 2551 2551p...@gmail.com mailto:2551p...@gmail.com wrote: Yes, that's precisely what I'm looking for and don't seem able to find. Can anyone suggest one? I've been all over stackexchange etc, and there seems to be a lot of confusion out there (or, rather, the more I read, the more confused I'm getting). I feel your pain. The crypto APIs are IMHO the worst designed APIs in OS X / iOS. (They're not even compatible between the two OSs; each one has annoying incomplete areas.) Apple has code samples called CryptoCompatibility and CryptoSample (the latter one doesn't seem to be in Xcode anymore but you can find it online) that show how to perform some basic tasks with the APIs, including signatures. IMO, it’s better to just static-link OpenSSL into the app and use that. Not only is there more documentation out there, but as OpenSSL is a cross-platform library. After all, you’re going to want some sort of automatic system for generating license codes for your users, and if you write your registration code in something cross-platform like plain C with OpenSSL, you can use the same code in the generator tool that goes on your website, without requiring the website to be hosted on OS X, which gives you a lot more flexibility in your web hosting. (Yes, it’s true that typically the code on your site and the code in your app will be doing different things — one encoding and the other decoding — but I prefer to have the generator immediately run the generated code through the validation system in order to be absolutely positive that the generated code is going to work in the app, and to send me an e-mail alert if any situation comes up where this is not the case.) Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On Jan 11, 2015, at 12:59 PM, Charles Srstka cocoa...@charlessoft.com wrote: IMO, it’s better to just static-link OpenSSL into the app and use that. Kind of big, though! libSodium* (based on NaCl) is a much smaller crypto library, which also has the benefit that it uses an elliptic-key algorithm, Curve25519, whose keys are a lot smaller than RSA's: 256 bits instead of 2048+. —Jens * https://github.com/jedisct1/libsodium ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 11 Jan 2015, at 21:59, Charles Srstka cocoa...@charlessoft.com wrote: IMO, it’s better to just static-link OpenSSL into the app and use that. Short caveat: Do not get the actual OpenSSL. Get LibreSSL, which is a fork of OpenSSL done by the OpenBSD folks (i.e. people who actually know security) done after all the brouhaha with that big bug making OpenSSL insecure. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
licence key validation method
Can anyone point me in the right direction for the (simplest) solution to validate a DSA key in my OS X app? I've looked at both CocoaFob and AquaticPrime; both contain deprecations and look as if they are more or less dead. In neither case have I been able to get my head around the incomplete / out-of-dae documentation to see a clear procedure for adding to my app. I've also looked at DevMate, but their pricing is, for a small-timer like myself and for what I want from them, utterly unrealistic. I'm using FastSpring, and I already have DSA key generation set up, with keys being generated and sent to my customers when they order. What I need to add to my app is a method to validate and store the key they receive ( (FastSpring's documentation on more or less just says see the 3rd party documentation). I'm not looking for anthing fancy. The simplest implementation will do, and an idiot's guide on how to do it would be ideal, but any pointers from anyone that's done this recently would be hugely appreciated. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 10 Jan 2015, at 10:33, sqwarqDev 2551p...@gmail.com wrote: I'm not looking for anthing fancy. The simplest implementation will do, and an idiot's guide on how to do it would be ideal, but any pointers from anyone that's done this recently would be hugely appreciated. Really, all you need is any asymmetric encryption/signing library. I think these days that would be Security.framework. So any tutorial on encrypting and validating messages will do. What you do is you generate a private and public key pair, then create a bit of data (e.g. a PList) that contains all the Info that you need for a valid license (e.g. user name, number of seats, major version of the app this is for, expiration date for demo licenses, and usually some sort of counter that you just increase by one whenever you generate a license, so you can tell apart various licenses bought by the same person, or people with the same name). Once you have this PList, you encrypt it (using your private key). You include your public key in your application, and the license-checking code simply decrypts the PList using that. You only get a valid PList out if the matching private key was used to encrypt it, so you now know that this is a real license generated by you, and can look at the PList entries to see what the user is allowed to do etc. A few notes and caveats: 1) Copy-paste the public key into the source code, don’t include it as a file, so people can’t just replace that file too easily. XOR an arbitrary value onto it to make it harder for people to just fire up HexEdit and search for “RSA key start” or whatever and replace that with a key they generated. 2) Beyond #1, it’s not really worth trying to protect against binary patches. You can binary patch away everything (At worst a hacker could patch out Security.framework), so whatever you do, hackers can break it. But anyone who runs a binary patch runs untrustworthy code on their machine and is probably catching a virus anyway. The thing you need to protect from are key generators, which you have by using a decent-size RSA key (until Quantum computers become common enough that people will just Shor away any RSA keys, at least). Keep your private key safe and you should be fine. 3) The amount of data you put in your key is directly related to the length of the key. So if you use a PList, you’re pretty much forced to have a key file. If you need users to copy the key as a string, make the real key a struct and choose smaller data types, so you get a shorter key. Hope that helps. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
Thanks for the overview Uli, and the pointer towards Security.framework. I'm working my way through the docs, but there's a lot that doesn't seem relevant to my task. Most of the rest in your outline I've got. However, it's these specific parts I'm struggling with and which prompted my initial question: any tutorial on...validating messages will do. Yes, that's precisely what I'm looking for and don't seem able to find. Can anyone suggest one? I've been all over stackexchange etc, and there seems to be a lot of confusion out there (or, rather, the more I read, the more confused I'm getting). You include your public key in your application, and the license-checking code simply decrypts the PList using that. Yes, I've got the public key in my app. I also have the encrypted licence for the user to insert. Its help with the simple licence-checking code to do the decrypting that I need. I'm going to spend the rest of the day working through the cocoafob and aquaticprime code and see if I can figure out what I need from there, but if anyone has done this themselves recently and can offer some guidance, pseudo-code or link to a tutorial, it'd be much appreciated. Security is not something I've tackled before, so this is a whole new mountain climb for me. Best Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: licence key validation method
On 11 Jan 2015, at 13:34, 2551 wrote: any tutorial on...validating messages will do. Yes, that's precisely what I'm looking for […] I wrote one a decade ago: http://sigpipe.macromates.com/2004/09/05/using-openssl-for-license-keys/ Previous thread here: http://prod.lists.apple.com/archives/cocoa-dev/2014/Nov/msg00072.html ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
