Symmetric encryption and re-signing of applications

Symmetric encryption

  • Symmetric encryption: The plaintext is encrypted using the key to obtain ciphertext. Ciphertext is decrypted by key to obtain plaintext.

Common algorithms

  • DES Data encryption Standard (used sparingly because it is not strong enough)
  • 3DEC used three keys to encrypt the same data three times, and when it got stronger, it almost died
  • AES Advanced Secret standard

To compare

  • Symmetric encryption
    • Encryption and decryption use the same key
  • Asymmetric encryption
    • Use public and private keys
  • HASH
    • Not an encryption algorithm

Symmetric encryption mode

  • ECB (Electrinic Code Book) electronic password Book mode. Each piece of data is encrypted independently
    • The most basic encryption mode, that is, commonly understood encryption, the same plaintext will always be encrypted into the same ciphertext, no initial vector, vulnerable to passbook replay attacks, rarely used in general
  • Cipher Block Chaining (CBC) encrypts data using a key and an initialization vector [IV]
    • Before the plaintext is encrypted, it must perform subsequent operations with the previous ciphertext before encryption. Therefore, the same ciphertext will be encrypted into different ciphertext as long as different initialization vectors are selected. This is the most widely used ciphertext mode. CBC encrypted ciphertext is context-dependent, but plaintext errors are not passed to subsequent groups, but if one group is lost, all subsequent groups are invalidated (synchronization error)
  • CBC effectively ensures the integrity of ciphertext. If a data block is lost or changed during transmission, subsequent data cannot be decrypted

Terminal practice value EBC

  • Create message. TXT file contents before encryption

    0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222Copy the code

  • Command to execute the encryption command

    openssl enc -des-ecb -K 616263 -nosalt -in message.txt -out msg1.bin
Copy the code
    • – DEC uses DES encryption
    • – ECB Uses the ECB mode
    • -k 616263 Secret is a capital ABC
    • -nosalt Does not use salt. Openssl generates random salt by default
    • TXT Indicates the encrypted file
    • -out msg1.bin Specifies the encrypted output file

  • Use CAT to view encrypted files

  • Use XXD to view

    • D1f8 0876 7a80 0184 These 8 bytes of data are duplicate

  • Change the message.txt file to change the 00 before the fourth line to 88

    0000000000000000000 1111111111111111111 2222222222222222222 8800000000000000000 1111111111111111111 2222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222Copy the code

  • Execute the encryption instruction again to generate MSg2.bin

    openssl enc -des-ecb -K 616263 -nosalt -in message.txt -out msg2.bin
Copy the code

  • A comparison of the two output files shows that only the red area is different

Terminal practice value CBC

  • Restore 88 in message. TXT to 00 before encryption

    0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222Copy the code
    0000000000000000000 1111111111111111111 2222222222222222222 8800000000000000000 1111111111111111111 2222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222 0000000000000000000 11111111111111111111112222222222222222222 0000000000000000000 11111111111111111111111 222222222222222222222Copy the code

  • Command has an initialization vector

    Openssl enc-des-cbC-k 616263-iv 01020304050608 -nosalt -in message. TXT -out msg3. TXT openssl enc -des-cbc -K 616263 -iv 01020304050608 -nosalt -in message.txt -out msg4.txtCopy the code
    • – DEC uses DES encryption
    • – CBC Indicates the CBC mode
    • -k 616263 Secret is a capital ABC
    • -iv 01020304050608 Initializes the vector
    • -nosalt Does not use salt. Openssl generates random salt by default
    • TXT Indicates the encrypted file
    • -out msg3.bin Indicates the encrypted output file
    • Perform twice

  • When you look at the results, the red area is different

PS, the current encryption algorithm, has to do with geometry where the variables are regular, and the results of the rules are variable for example, a point on the original, can have an infinite number of vectors, and the results are infinite. PS -k 616263 can also be changed to -k ABC, can also use the string PS CCCrypt security problems using the system encryption method is not safe can be broken debugging * parameter can be xOR operation first, then encryption, When decrypting, decrypt first, and then xor obtain the plaintext. But confusing parameters can still be debugged. That’s the easiest way. Can also do parameters do encryption first, and then call the system encryption method * their own encapsulation method can be used to confuse the system method there is no way to confuse

Re-signing the application

IOS code signing

  • Code signing is the digital signing of executable files or scripts. A measure used to confirm that software has not been modified or corrupted after being signed. The principle is the same as digital signature, but the data of signature is code.

Simple code signing

  • Before iOS came out, the previous mainstream operating system (Mac/Windows) software can be downloaded from anywhere, there are hidden dangers in system security, pirated software, virus intrusion, silent installation and so on. So Apple wants to solve this problem, to ensure that every App installed on iOS is approved by Apple official, how to ensure? That’s code signing
  • The easiest way to verify this is through a pair of asymmetrically encrypted public and private keys generated by Apple. There is a built-in public key in the iOS system, and the private key is saved by the Apple background. When we upload the app to AppStore, the Apple background uses the private key to digitally sign the app data. After downloading the APP, the iOS system uses the public key to verify the signature. If the signature is correct, the app must have been authenticated by Apple and has not been modified, which meets Apple’s requirement that every app installed is approved by Apple.
  • If our iOS device installed the app from the AppStore as a single entry point, this would be easy to solve, nothing complicated, just a digital signature.
  • But there are actually other ways to install apps on iOS. For example, for our developer iOSer, we need to debug the real machine directly when developing the app. Apple has also developed a distribution channel within the enterprise, and the enterprise certificate signing app needs to be installed smoothly
  • Apple needs to develop these ways to install apps that can’t be met with a simple code signature

Apple’s needs

  • The installation package does not need to be uploaded to the AppStore and can be installed directly on the phone
  • In the future, Apple will have to guarantee the security of the system, but also have absolute control over the apps installed
    • Install with Apple’s permission
    • Cannot be abused so that non-development apps can be installed
  • Future implementation of these requirements, the complexity of iOS signature will begin to increase, Apple here provides a solution for two-layer signature

Two-layer signature process

  • To prepare
    • Xcode helps us generate a pair of public key M and private key M on the Mac
    • The public key A delivered by Apple is saved on the iPhone
    • Private key A saved on the Apple server
  • Apply for a certificate through CRS file * The MAC generates a CSR file using the public key M + organization information and sends it to the Apple server
  • For Apple ServerThe private key is AencryptionPublic key MTo generate a certificate
    • The certificate contains the public key M and the Hash value of the public key M. The certificate is the DER file and will be delivered to the MAC.
    • This certificate can only be decrypted by mobile phone.
    • The public key M and private key M in this book are a pair
    • The private key M is p12. The certificate is bound to the certificate during keystring access
    • After the request is returned, the certificate is bound to p12
  • Developers create apps that useThe private key M(P12) To generate a signature of app
    • MachO, signatures, and certificates are all packaged in the app
    • The MAC installs the app on top of the phone
  • Phone verification

    • Apple’s public key A decrypts the certificate and obtains public key M

    • The public key M can parse the app signature and verify the app signature. If the verification succeeds, the installation is authorized by Apple

PS P12 can go around and give to other developers and other developers can sign apps and install them on mobile devices and the PS app’s signature is encrypted to the Hash value of Macho

There is a problem with applying for a certificate that can be installed on any device. Don’t upload the AppStore. So Apple limits the number of devices on which certificates can be installed, and limits the duration

  • A restricted file is a permission file, which becomes a profile file

  • The description file is installed in the app

  • Profiles are also signed, so it’s useless to change anything

  • Signature information for machO files

conclusion

  • Symmetric encryption
    • AES DES 3DES
    • EBC CBC
    • The iv vector is 8 bytes
  • Application Signature Principle
    • Personal public key M Private key M Official public key A and private key A
    • Description file