![]() The contents of the set are the receipt attributes. The three following bytes encode the length of the set's content. The figure below shows how a receipt module is encoded: To better illustrate the concept, here are some concrete examples of DER-encoded content applied to a receipt. DER uses a pattern of type-length-value triplets and byte constants for each type tag. This kind of encoding provides an unequivocal and compact result for ASN.1 structures. The payload is encoded using DER ( Distinguished Encoding Rules). The value field contains the data as an array of bytes (even if its name may suggest it, this is not a string). You may also find unlisted attributes while parsing a receipt, but it's best to simply ignore them (mostly because they are reserved by Apple for future use). Apple has published a list of public attributes that can be used to extract information from the receipt. The type field identifies each attribute by its type. The ASN.1 payload is defined by the following structure: The certificate chain is validated against the Apple Certificate Authority Root certificate - this is the authenticity check.Ī signature is computed using the certificate chain and compared to the one found in the container - this is the integrity check. To verify the signature, two checks are needed: The container's signature guarantees the authenticity and the integrity of the encapsulated payload. The receipt container is a PKCS #7 envelope, which is signed by Apple with a dedicated certificate. By checking this digest, you can verify that the payload has not been tampered with. The signature is the encrypted digest of the payload. The certificate chain is the set of certificates required to properly verify the signature digest - the leaf certificate is the certificate that has been used to sign the payload. Among the attribute values, you find the bundle identifier and the bundle version for which the receipt was issued. The payload is a set of attributes that contains the receipt information each attribute contains a type, a version, and a value. Its structure looks like this:Ī receipt file consist of a signed PKCS #7 container that embeds a DER-encoded ASN.1 payload, a certificate chain, and a digital signature. Let's take a technical look at the receipt file. In this article, we'll take a look at the mechanics and best practices of receipt validation. In the interest of full disclosure, I'm the author of Receigen, a Mac app used to generate secure and changing receipt validation code. So it's important to develop a solution that is unique and secure enough to resist common attacks. Of course, there are several off-the-shelf implementations available (for example, on GitHub), but they are often just reference implementations and suffer from the same problem outlined above if everybody uses them: it becomes very easy for attackers to crack the validation code. However, this is not an easy process, and it requires a good understanding of cryptography and of a variety of secure coding techniques. Instead, Apple made the choice to use standard cryptography and encoding techniques, and to provide some help - in the form of documentation and WWDC sessions - for implementing your own receipt validation code. Since every developer would use the same validation method, hacking would be too easy. An attacker would simply look for this selector inside the binary and patch the code to skip the call. ![]() For the sake of demonstration, imagine that such a method exists (for example, validateReceipt]). You may wonder why Apple hasn't provided a simple API to validate the receipt. Verifying receipts is a mechanism that helps you to protect your revenue and enforce your business model directly in your application. When previous transactions are restored, a receipt is issued so that it can be accessed to verify those purchases. ![]() When an in-app purchase occurs, a receipt is issued so that it can be accessed to verify that purchase. When an application is updated, a receipt that matches the new version of the application is issued.Ī receipt is issued each time a transaction occurs: When an application is installed, a receipt that matches the application and the device is issued. While iOS has always provided server-side receipts for in-app purchases, it was only with iOS 7 that iOS and OS X began to share the same receipt format.Ī receipt is meant to be a trusted record of a purchase, along with any in-app purchases that the user has made - much like a paper receipt that you get when shopping in a store.Ī receipt is created and signed by Apple through the App Store.Ī receipt is issued for a specific version of an application and a specific device.Ī receipt is stored locally on the device.Ī receipt is issued each time an installation or an update occurs. Receipts were introduced alongside the release of the Mac App Store, as part of the OS X 10.6.6 update. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |