ࡱ> M HBbjbj== 2`WW#>$l6666666J8(LJfhL($  6 66 p66$ rT66t @ FJw$60f 5JJ6666TigerCad Copy Protection & Licensing Requirements Definition & Architectural Specification  HYPERLINK "mailto:peterhoward42@blueyonder.co.uk" peterhoward42@blueyonder.co.uk  HYPERLINK "http://peterhoward42.blogspot.com" http://peterhoward42.blogspot.com Abstract This document presents the software licencing scheme the author designed and developed for TigerCad a low cost CAD application. The document sets out requirements and then presents designs to meet the requirements. The source code is also available for free download  HYPERLINK "http://www.peterhoward42.pwp.blueyonder.co.uk/licencing_code.zip" here. Although, please note that this code has been lifted out from the application without ceremony or organisation so some detective work will be necessary. Requirements The distribution model for TigerCad is to encourage as many people as possible to install, and re-distribute it onward. This is to exploit the marketing side effect of such a model, and to get potential customers hooked. Most features in the application will require a key to be purchased in order to work. Specifically, a key will be created which unlocks these program features, on a specific computer, either permanently, or for a 30 day extension. It is likely that keys will be issued free for a trial period. The solution must render this practical. The solution must resist fraud. It doesnt matter if a determined expert can crack their own copy and gain fraudulent use of the program on one computer that would not represent significant (if any) revenue loss. Nor would it be catastrophic if a cracker managed to create an open version, because the cracker would be discouraged from high profile publication of such an open version due to personal risk. Also end users would be reluctant to risk using it, and it is doubtful if those that did would have bought it anyway. We are principally interested in making it reasonably difficult for people who are seriously considering buying the package to use an illicit copy, or fraudulently extending a free trial. The solution must prevent a cracker from publishing a simple recipe to defeat the packages security measures. The fraud protection measures must not interfere with a users ability to upgrade to a later version of the software, or a patched version. The solution must not require special hardware. The solution must not require registration by the user this will kill a significant proportion of sales because of some peoples attitudes. Customers will have to interact with the web site to a degree, but this must be made as anonymous as possible emulate as far as possible the vending machine paradigm. The sales model is to sell a key for a specific computer. There are potential problems with this. Firstly, the definition of a single computer is ambiguous. Secondly, it is impossible for the implementation of licence checking to check this in a way that would satisfy all customers. We want to give users the benefit of the doubt as a matter of goodwill and PR. We will invite them to email us with an appeal if they have any licensing problems, and will virtually always give them the benefit of the doubt. The upside of this is goodwill in the user community. The downsides are administrative overhead, and the potential for abuse. We have to live with the former in the interests of PR and goodwill (like high street retailers). The latter will not significantly hit revenue. Few fraudsters will attempt to appeal by email. The solution must provide for this technically. (A website form will also be available for this in case someone hasnt got email set up, but has got internet access). The process for issuing keys must be automatic at the vendor end. The solution must not depend on client-side software running in a browser (Java / ActiveX) because a minority of people will have this disabled. The only client-side software that we can depend on is what we ship with the installation, and of course the application itself. It follows that users will have to type something in on their machine. This must not be too onerous i.e. the key they have to type must not be too long. We cannot rely on cut and paste because the user might use a different machine to buy the key, from the destination machine. The solution must not require different versions of the package to exist. Statistically probable errors must be catered for in the process. For example, a user mistyping and then losing a key. An audit trail must be left by the key-issuing process for problem investigation purposes, and to rescue people who paid for a key and lost it or wrote it down wrong. The solution will inevitable require internet access, but it should not be necessary that this be from the installation target machine. Once a paid-for key has been issued, the solution must provide for rescuing people when things go wrong. We cannot risk people paying for the key and then not being able to use it for any reason. Drawing files must remain portable. For example no non-portable security data must not be stored in them. Some features must not require keys at all. For example read-only operation, and DXF out. This latter feature is to encourage people to do the free trial, knowing they can protect their investment in creating drawings if they decide not to take up the purchase option. Solution Overview A simple check for the presence of an edit licence is made every time most TigerCad commands are used. The edit licence is manifested by an encrypted and tamper-proofed expiry date in the registry. The encoding of this will be bound to the host machines identity to prevent the licence from being useful on a different machine. PCs running Windows do not have an intrinsic and robust identity, so TigerCad will create one at installation time, and store it in the registry, in a tamper-proof and non-portable way. This is explained more fully below. TigerCad Identity Ultimately the identity is a string in the registry. The identity must: Differ on all machines Be verifiable at run time as belonging to the machine Not be predictable by the public for other machines Not reveal how a machine could be altered to match another identity Remain unchanged when the host machine is altered or reconfigured in the most common ways. It will be formed by concatenating the formatted install time and the formatted C:/Windows creation time. The resultant string is then encrypted, and converted to a human readable string format before being posted to the registry. RequirementMet because1Install time is used.2C:/Windows creation time can be cross-checked3Encryption renders the encoding confidential4Encryption renders the encoding confidential5C:/Windows creation time is seldom changed The run-time edit-licence requests will incorporate the identity being read and validated every time. When security appears to be compromised, the licence request is declined. Terminology, Data Formats, & Encryption This document describes a set of key-like entities. This section defines their common properties and nomenclature. Raw Data Their underlying defining data is a CArray of unsigned chars. In some cases, but not all, the chars will be ASCII encoded, but the array does not include a terminator. This underlying defining data is referred to as the raw data. Cooked Data Raw data is secret, and is never exposed. To protect its confidentiality it is RC4 encrypted. Constant encryption keys are used. Different keys are used for each context, to hide the similarities of parts of some raw data (e.g. high order parts of dates). This processed data is denoted as encrypted data and uses identical storage to raw data. Data that is exposed to users, must of course be human readable, and it is convenient to use string representations in the registry. For this reason a further transformation is available to convert encrypted data to human-readable data. This formats each byte of the input to a pair of ASCII hex digits and populates a CString with the result. Nb the string representation is twice the length of the raw ignoring terminators. Dates Users will have to advise us of their TigerCad identity when buying keys, so the human readable form must not be excessively long. The identity has to model two dates, so space is at a premium. The raw data for dates are modelled in whole numbers of days since 2000, and formatted as decimal ASCII, in a field width of 4. Consequently the human readable form for an identity requires 16 printable characters. The Edit Key This section covers the format and scrutiny process for the edit key. Later sections detail the methods for it being installed. The edit key encapsulates the edit licence expiry date. A special reserved (past) date is reserved to signify a permanent licence. The licence is granted when the system time is earlier than the encoded expiry date. (System clock tampering is dealt with later). The edit key must: Encode an expiry date Be verifiable at run time as matching the machines identity Not be predictable for a different machine Not be predictable for a different date Two keys are used the expiry date key and a signature key. The expiry date key is simply the expiry date encoded as described above. The signature key is responsible for binding the expiry date to the identity. The raw data for it is formed by taking the MD5 message digest of the identity and the expiry date concatenated together. The human readable form for this requires 32 bytes, but it doesnt matter that this is rather long because users never have to type it. The run time verification that the expiry date is bound to the identity, is to generate the message digest from the identity and the expiry date, and to make sure it matches that stored in the signature key. RequirementMet because1Date is encoded in edit key2Signature check available3Even if you work out that the signature is an MD5 digest, you cannot access the raw data that forms the input message.4Encryption protects the encoded date to a degree. But not brilliantly, because the high order bytes wont change if you extend a licence for an additional 30 days. However, even if you crack the expiry date, it wont work without also cracking the signature. Free Trial Installation The installation process by definition, installs a 30 day edit licence. The installation code can synthesise the raw data required for both the identity, expiry date and signature, and post the appropriate entries to the registry. Protection is required against attempts to fraudulently repeat installations on the same machine, to get repeated free trials. The solution must resist un-installation, a bit of creative registry editing, or a Windows XP system-rollback. That means that nave encoding of TigerCad was here into the registry is inadequate. This will be done to provide the first line of defence, and an unambiguous error report to the user, but additional measures are required (below). We could scatter some hidden data in amongst the file system, but this would probably upset the community and could generate a bad press. A better solution is to exploit the data TigerCad owns i.e. the drawing files. TigerCad will maintain a registry entry which will have two states: Currently running a free trial Currently running something that has been paid for. This entry will be initialised during installation and toggled when a licence is upgraded. Requirements for this registry data are: Discriminate between two states Model date of free trial install Different on each machine Non predictable Concealed meaning Use two keys. The first is an expiry date key which holds a reserved date to signify something paid for, or the free trial commencement otherwise. The second is a signature to bind it to the id, via an MD5 digest. Every time TigerCad saves a drawing, this state is encoded into the drawing file, along with the date the free trial started when relevant. We hence have a persistent record of the free trial having been underway embedded in the drawings created. Furthermore, this data is beyond the reach of the user. We dont attempt to spot re-installation fraud during installation beyond the inspection of the nave registry key., but wait until drawings are opened by the application. When TigerCad is paid-up, we dont check. When it is in free-trial mode, we check that any drawings that are opened, and which record internally that they were created during a free trial, have the same free trial commencement date as we have hence raising no problems for a legitimate first free trial. If the dates dont match, we say You cannot open this drawing during YOUR TigerCad free trial period, because it belongs to a DIFFERENT trial period. This is a fraud protection measure to prevent people trying to get repeated free trials. Your options are: If the drawing file was created by another TigerCad user with a paid-for licence, ask them to re-save the drawing and give you the new file, which will then work. Appeal to us at  HYPERLINK "mailto:support@TigerCad.com" support@TigerCad.com, attaching the problematic drawing, and explaining your legitimate background circumstances. We will consider sending an unlocked version back to you. Purchase a licence yourself. (From TigerCad launch screen). Purchasing Keys The basic model for purchasing keys, is that the user quotes their TigerCad identity and hands over the money on the web site. The site must then respond with a string for them to type in which encapsulates the message this message hereby grants a 30 day extension (or permanent) licence to the machine with TigerCad identity xyz. This is called the purchase message. The purchase message must: Encode which type of licence has been purchased Be verifiable at run time as matching the identity Not be predictable for a different identity Be substantially different between permanent and temporary licences Be reasonably short The messages raw data will be formed by making an MD5 message digest from the identity and a constant string like 30 days concatenated together. MD5 digests are 16 bytes long which when converted to the human readable form is excessive. So the raw data will be reduced by truncation to 8 bytes, leading to 16 character strings for the user. At the installation end, the application can synthesise the truncated digests expected for the machines identity with both the 30 day constant string, and the permanent string. If either matches that provided by the user, it knows a legitimate licence has been purchased. Once the decision to install the licence has been made on the basis of the existing identity, then identity is reset to render the purchase message defunct thereafter. Additional Security Measures Changing the Clock The licence is expiry-date based, so we must protect against the machine clock being turned back. Each edit licence check will post an encrypted version of the time the application was most recently used into the registry. It will then object later to this stored time being in the future. Protect the binaries The shipped binary programs will be stripped or whatever the Windows equivalent is, to remove symbolic information that could aid assembly-level hacking attempts. Failure Recovery The application will present a trouble-shooting screen to users struggling to input a new key. It will explain the basics and invite legitimate users to email TigerCad with the circumstances for help. We reply with password that lets them generate a new identity, and when they tell us that, we can issue new licences by hand. The web site provides a lookup of keys issued against identities to help people who lose the number or write it down wrong. The application case converts and fixes hexadecimal input where possible. Page  PAGE 1 of  NUMPAGES 7 Z[]^ #$rstxy ""#$#**4.C.L7M7v7w7x77799#B(B)B/B0B1B2B6B7BABBBźźmHnHsH ujUmH sH mH sH j9U6]5\0Jj.U jUjCJUaJ 0JCJaJ jCJUaJ CJaJ jCJUaJ CJ B*ph: %[\]  #R S   J K $a$!#BGBjk#$CD ghGY & F>#g~d~k$$Ifl0 5064 la  9r $If 9r  & F>>?AnoqNO 9r k$$Ifl0 5064 la  9r $IfOw ##%%&&''1'G'''''****  9r $If 9r  & F?*********O+P+R+T,U,V,W,|t  9r $Ifk$$Ifl0 5064 laW,o,V-W-0/1/00S0r0011+1K1l1111122335555 & FD & FB5*6+6666<7%8a8b8r899:0:c:::::P=Q==>)>K?`? 9r  & FA & FC^ `?@@]A#BEBFBGBHBBBCBDBHBjUmH sH mHnHsH u0&P 1h. A!"#$% DyK peterhoward42@blueyonder.co.ukyK dmailto:peterhoward42@blueyonder.co.ukyX;H,]ą'cDyK "http://peterhoward42.blogspot.comyK ^http://peterhoward42.blogspot.com/yX;H,]ą'c DyK yK http://www.peterhoward42.pwp.blueyonder.co.uk/licencing_code.zipyX;H,]ą'cDyK support@TigerCad.comyK 8mailto:support@TigerCad.com# i>@> Normal$a$CJ_HaJmH sH tH \@\ Heading 1'$ & FQ<@&^`Q5CJOJQJB@B Heading 2  & F@&CJ\]^JaJ8@!8 Heading 3  & F@&\aJLL Heading 4$ & F<@&OJQJ\aJLL Heading 5 & F<@&56CJ\]aJFF Heading 6 & F<@&5CJ\aJ88 Heading 7 & F<@&>> Heading 8 & F<@&6]L L Heading 9 & F<@&CJOJQJ^JaJ<A@< Default Paragraph FontJYJ Document Map-D M OJQJ^J66 Normal Indent ^J>J Title*$$d&dNPa$CJ66TOC 1$a$5\mHnHu&& TOC 2 ^&& TOC 3 ^&& TOC 4 ^&& TOC 5 ^&& TOC 6 ^&& TOC 7 ^&& TOC 8 ^&& TOC 9 ^,@, Header  9r , @, Footer  9r .U@. Hyperlink >*B*ph>V@> FollowedHyperlink >*B* ph<C< Body Text Indent ^@R@@ Body Text Indent 2 ^ROR Doc Title*!$$d&dNPa$CJ(!"( typewriter"H>` %[\]  #RS  J K jk#$CD ghGY#g>?AnoqNOw!!""##1#G#####&&&&&&&&&&&&O'P'R'T(U(V(W(o(V)W)0+1+,,S,r,,--+-K-l-----..//1111*2+2222<3%4a4b4r455606c66666P9Q99:):K;`;<<]=#>E>I>!0!0!0000000 00 0 0 00z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z0z 00p0p0p 0000> 0> 0> 0> 0> 0000000000000000000000000 00 00N 00=( 0==0N 00 0 0 0 0 ? 0 ? 0 ? 0 ? 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  00'0'0'0'0'0'0'B 0'B 0'0'0'0'D 0'D 0'D 0'D 0'D 0'0'0'0'0'0'0'0'0'0' 0'0'0'0'0'C 0'C 0'C 0'0' 0030303A 03A 03A 03A 03A 0303030303 0 0]9]90z9 0]9]90: 0 00@0 0###&BBHB$/O*W,5`?HB%'()*+,-.GB&]#sxL3w33H>XXXX  &!ttl,R$e$'q@0(  B S  ?H>7@ow }#>F>I>Z[****++-~.o2w2L3x333a4a4J;<">#>(>2>6>D>F>I>$Z[****++-~.o2w222 3`4a4a4J;<">#>(>2>6>D>I> Peter HowardTC:\Documents and Settings\Owner\My Documents\Isabelle\Tech Docs\Copy-Protection2.doc Peter HowardTC:\Documents and Settings\Owner\My Documents\Isabelle\Tech Docs\Copy-Protection2.doc Peter HowardTC:\Documents and Settings\Owner\My Documents\Isabelle\Tech Docs\Copy-Protection2.doc Peter HowardTC:\Documents and Settings\Owner\My Documents\Isabelle\Tech Docs\Copy-Protection2.doc Peter HowardTC:\Documents and Settings\Owner\My Documents\Isabelle\Tech Docs\Copy-Protection2.docPeterC:\pch\pws\Copy-Protection2.docPeterC:\pch\pws\licenceing.docPeterC:\pch\pws\licenceing.docPeterC:\pch\pws\licenceing.docPeterC:\pch\pws\licencing.docD$PuHg%gJ*>-(phvc `8" z ,ChnF .rVL~f#@Hʝct{P|^@?N҈c?6b;$J2 ,(X\i,iS\,at-}p Ug. ~(Y.&HvSN(w/@CJ4{{p7h9<"8X',8vW|Qv:4߶ ?;RsHb>BCW?d2m?dH@lr`Bf-WlBF`vcl C2~ C*|FDV>"<BD5j~G"4bX$L`0D~MIzZiN̄92N'JHRP=  SZU!]"{-f]tTd_֖`B CGrj$hn*c 8" f]X$LLuyw/|@?!]?Anoq&&&&&&&&&&&O'P'R'T(U(I>@DH>@@UnknownGz Times New Roman5Symbol3& z Arial5& zaTahoma?5 z Courier New;Wingdings"1HhEEFa&<3m"0d> 2q<C:\WINDOWS\Application Data\Microsoft\Templates\Isabelle.dotIsabellexxPeterOh+'0p   , 8 DPX`h Isabelle sabxxbxb Isabelle.dotoPeterle6teMicrosoft Word 9.0@ԭ@F3@@pjE<3՜.+,D՜.+,4 hp|  om>  Isabelle Titlel 8@ _PID_HLINKSA$; mailto:support@TigerCad.com%Ahttp://www.peterhoward42.pwp.blueyonder.co.uk/licencing_code.zipz#http://peterhoward42.blogspot.com/n&mailto:peterhoward42@blueyonder.co.uk  !"#$%&'()*+,-./02345678:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F@ FData 11Table9WordDocument2`SummaryInformation(DocumentSummaryInformation8CompObjjObjectPool@ F@ F  FMicrosoft Word Document MSWordDocWord.Document.89q