RU2809740C2 - Method for processing file stored in external memory - Google Patents

Abstract

FIELD: computer technologies.

SUBSTANCE: invention relates to a method, a chip and a computer-readable storage medium for processing a file stored in an external memory. The method is applied to an electronic device, wherein the electronic device includes an internal memory that contains an erasable section and a non-erasable section, and the electronic device is connected to an external memory, wherein the method comprises: displaying an external memory encryption setting interface; receiving the first operation that is performed by the user at the encryption setting interface, wherein receiving the first operation that is performed by the user at the encryption setting interface comprises: receiving an encryption instruction, wherein the encryption instruction instructs to encrypt the first file stored in the external memory; encrypting the first file stored in the external memory using the second key in response to encryption instructions; obtaining the first account ID based on the encryption instruction; encrypting the first key based on the first account identifier to generate the first ciphertext, the first key being used to encrypt the second key; encrypting the first account identifier to generate the second ciphertext; and storing the first ciphertext and the second ciphertext in an non-erasable partition; receiving the second user operation; displaying the factory reset setting interface in response to the second operation; receiving a third operation that is performed by the user in the factory settings interface; performing a factory reset in response to the third operation, in which the data in the erasable partition is deleted during the factory reset, and the data in the non-erasable partition is retained during the factory reset; displaying the account verification interface; receiving verification information that is input by the user in the account verification interface; and checking the first account ID based on the verification information, when the first account ID is verified successfully, and, when an operation in which the user accesses the first file in the external memory is received, decrypting the first file encrypted in the external memory based on the first ciphertext and the second ciphertext stored in a non-erasable partition.

EFFECT: increased security of file storage in external media.

14 cl, 20 dwg

Description

Cross reference to related application

This application claims the benefit of Chinese Patent Application No. 202110566480.8, filed with the National Intellectual Property Office of China on May 24, 2021, entitled "METHOD FOR SAVING CIPHERTEXT AND APPARATUS", which is incorporated herein in its entirety by reference.

Field of technology to which the invention relates

The present application relates to the field of terminals and, in particular, to a method for storing ciphertext and an apparatus.

State of the art

With the advent of data-intensive services such as Enhanced Mobile Broadband (eMBB) and high-definition video, electronic devices are faced with the problem of running out of storage space. External storage (such as a secure digital (SD) card) connected to an electronic device can solve the problem of running out of storage space. To ensure data security, data in external memory must be encrypted and stored.

The external storage key is encrypted using the lock screen password and then stored in an erasable partition of the electronic device. When a user performs a factory reset on an electronic device, the encrypted key (namely, the ciphertext) in the erased partition is deleted before being saved, and therefore the data in the external memory cannot be decrypted.

The essence of the invention

The present application provides a ciphertext storage method and apparatus to solve the technical problem that data in an external memory cannot be decrypted after an electronic device has been reset to factory settings.

According to a first aspect, there is provided a method for storing ciphertext, including: receiving an encryption instruction, where the encryption instruction instructs to encrypt a file in an external memory; obtaining the first account identifier's own value based on the encryption instruction; encrypting a first key using the first account ID's own value to generate a first ciphertext, where the first key is used to encrypt a second key, and the second key is used to encrypt a first file in the external memory; encrypting the eigenvalue of the first account identifier to generate a second ciphertext; and storing the first ciphertext and the second ciphertext in an indelible section.

The encryption instruction is an instruction that is initiated when the user encrypts the external memory in the encryption setting interface. Upon receiving the encryption instruction, the electronic device generates the first ciphertext and the second ciphertext and stores the first ciphertext and the second ciphertext in an indelible section of the electronic device. Thus, before the user performs a factory reset of the electronic device, the electronic device has completed securely storing the first ciphertext and the second ciphertext. After the factory reset is completed, the electronic device can recover the first key from the non-erasable partition, and then decrypt the second key in the external memory using the first key, and decrypt the file in the external memory using the second key, thereby solving the problem that the file in external memory cannot be decrypted after factory reset.

Optionally, the method further includes: obtaining pointer information for switching an account; checking the first account ID based on the index information; obtaining its own value of the second account identifier after checking the first account identifier; and updating the first ciphertext and the second ciphertext based on the self value of the second account ID.

The user can switch the currently registered account ID (such as the first account ID) in the account login interface. After the user initiates the electronic device to generate account switching instruction information at the account login interface, the electronic device may prompt the user to input a password corresponding to the first account ID to verify the first account ID. After checking the first account ID, it indicates that the user who changes the account ID is a valid user. The electronic device may receive a second account ID entered by the user, calculate a hash value (an example of an eigenvalue) of the second account ID, and then update the first ciphertext and the second ciphertext using the hash value of the second account ID. The electronic device may first decrypt the first key, then generate an updated first ciphertext using the hash value of the second account identifier, and then generate an updated second ciphertext using the hash value of the second account identifier. In the above solution, after determining that the current user (the user who changes the account ID) is a valid user, the first ciphertext and the second ciphertext are updated with the account ID (the second account ID) of the current user, and the rights to Encrypting and decrypting the external memory corresponding to the first account ID, thereby ensuring the security of the data in the external memory.

If necessary, the method further includes: checking the first account ID after the factory reset is completed; and, when the first account ID is successfully verified, decrypting the first ciphertext and the second ciphertext to generate the first key.

Once the electronic device performs a factory reset, the account verification mechanism is activated. The mechanism requires that the electronic device can only be used normally after successful account verification. The last registered account ID (such as the first account ID) that is verified before factory reset, and this can ensure that the user of the electronic device after performing a factory reset is a valid user, so as to ensure the security of data in the external memory.

If necessary, verification of the first account ID includes:

checking the first account ID when factory reset protection (FRP) is triggered.

Optionally, the method further includes: encrypting a first key using a default value to generate a third ciphertext; default encryption to generate fourth ciphertext; and storing the third ciphertext and the fourth ciphertext in an indelible section.

Since the user can switch accounts, there is a risk of leakage if the electronic device continues to use, after performing a factory reset, the first account ID or the second account ID to encrypt and store the first key. After decrypting the first key, the electronic device can use the default value to encrypt and store the first key, thereby ensuring the security of the data in the external memory.

Optionally, the method further includes: copying a third ciphertext and a fourth ciphertext from the non-erasable section to the erasable section; generating a first key based on the third ciphertext and the fourth ciphertext in the erased section; and decrypting, based on the first key, the first file encrypted in the external memory.

Optionally, before verifying the first account ID, the method further includes: receiving a factory reset instruction that is initiated by the recovery interface; and formatting the data in the erased partition based on the factory reset instructions.

Optionally, encrypting the first key using the first account identifier's own value includes: calling the key management module's key master TA to encrypt the first key using the first account identifier's own value. Encrypting the native value of the first account ID involves: calling the key master TA to encrypt the native value of the first account ID.

Optionally, storing the first ciphertext and the second ciphertext in the non-erasable section includes: calling a trusted execution environment application programming interface to store the first ciphertext and the second ciphertext in the non-erasable section.

If necessary, the first key is additionally used to encrypt the third key, and the third key is used to encrypt the second file, which is encrypted in the external memory.

Optionally, the method further includes: obtaining a custom lock screen password value based on the encryption instruction; encrypting the first key using the lock screen's own password value to generate a fifth ciphertext; encrypting your own lock screen password to generate a sixth ciphertext; and storing the fifth ciphertext and the sixth ciphertext in the erasable section.

Optionally, encrypting the first key using your own lock screen password value involves: Calling the key master TA to encrypt the first key using your own lock screen password value. Encrypting your own lock screen password value involves: calling the keymaster TA to encrypt your own lock screen password value.

Optionally, the method further includes: receiving a user reset instruction that is initiated by the configuration interface; and backing up the fifth ciphertext and the sixth ciphertext to a non-erasable partition based on the user's reset instruction.

Optionally, backing up the fifth ciphertext and the sixth ciphertext to the non-erasable partition based on the user reset instruction includes: decrypting a first key from the fifth ciphertext and the sixth ciphertext based on the user reset instruction; encrypting the first key using a default value to generate a seventh ciphertext; default encryption to generate the eighth ciphertext; and storing the seventh ciphertext and the eighth ciphertext in an indelible section.

Optionally, the method further includes: copying a seventh ciphertext and an eighth ciphertext from the non-erasable partition to the erasable partition after the user reset is completed; decrypting the first key from the seventh ciphertext and the eighth ciphertext in the erased section; and decrypting, based on the first key, the first file encrypted in the external memory.

Optionally, the partition being erased is the data partition, and the lock screen password's own value is a hash value of the lock screen password.

Optionally, the non-erasable partition is the sec_storage partition, and the first account ID's own value is the hash value of the first account ID.

According to the second aspect, another method of storing the ciphertext is provided, including: displaying an external memory encryption setting interface; receiving a first operation that is performed by the user in the encryption setting interface; encrypting a file in external memory in response to the first operation; receiving a second user operation; displaying the factory reset setting interface in response to the second operation; receiving a third operation that is performed by the user in the factory settings interface; performing a factory reset in response to the third operation; displaying the account verification interface; receiving verification information that is entered by the user in the account verification interface; and, when the verification information is verified and, when an operation in which the user accesses a file in the external memory is received, decrypting the file encrypted in the external memory.

The encryption instruction is an instruction that is initiated when the user encrypts the external memory in the encryption setting interface. Upon receiving the encryption instruction, the electronic device generates the first ciphertext and the second ciphertext and stores the first ciphertext and the second ciphertext in an indelible section of the electronic device. Thus, before the user performs a factory reset of the electronic device, the electronic device has completed securely storing the first ciphertext and the second ciphertext. After the factory reset is completed, the electronic device can recover the first key from the non-erasable partition, and then decrypt the second key in the external memory using the first key, and decrypt the file in the external memory using the second key, thereby solving the problem that the file in external memory cannot be decrypted after factory reset.

According to a third aspect, there is provided an apparatus for storing ciphertext, including a unit configured to perform a method according to any of the first aspect or the second aspect. The device may be a terminal device or may be a chip within a terminal device. The device may include an input unit and a processing unit.

When the device is a terminal device, the processing unit may be a processor, and the input unit may be a communication interface. The terminal device may further include a memory, and the memory is configured to store computer program code. When the processor executes the computer program memory code, the terminal device is able to execute the method according to any of the first aspect or the second aspect.

When the device is a chip in a terminal device, the processing unit may be a processing unit within the chip, and the input unit may be an output interface, output, circuit, or the like. The chip may further include memory. The memory may be memory (eg, a register or cache) on the chip, or may be memory (eg, read-only memory or random access memory) located off-chip. The memory is configured to store computer program code. When the processor executes computer program code that is stored in memory, the chip becomes capable of executing any of the first aspect or the second aspect.

According to a fourth aspect, a computer-readable storage medium is provided. A computer-readable storage medium stores computer program code. When computer program code is executed on a device for storing ciphertext, the device may perform a method in accordance with any of the first aspect or the second aspect.

According to a fifth aspect, a computer program product is provided. The computer program product includes computer program code. When computer program code is executed on a device for storing ciphertext, the device may perform a method in accordance with any of the first aspect or the second aspect.

Brief description of drawings

Fig. 1 is a schematic representation of a hardware system that is applicable to a device according to this application;

fig. 2 – diagram of the software system that is applicable to the device according to this application;

fig. 3 – schematic representation of the encryption settings interface according to this application;

fig. 4 is a schematic representation of the encryption confirmation interface according to this application;

fig. 5 is a schematic representation of the encryption processing interface according to this application;

fig. 6 – schematic representation of the method for storing the key according to this application;

fig. 7 – schematic representation of the encryption procedure according to this application;

fig. 8 is a schematic representation of a method for backing up and restoring a key in a user reset scenario according to this application;

fig. 9 is a schematic representation of a condition for changing the storage of ciphertext in a storage area in a user reset scenario according to the present application;

fig. 10 – schematic representation of the key backup method in the factory reset scenario according to this application;

fig. 11 is a schematic representation of the login interface using an account according to this application;

fig. 12 is a schematic representation of a condition for changing the storage of ciphertext in a storage area that exists when switching an account according to the present application;

fig. 13 is a schematic representation of the factory reset setting interface according to this application;

fig. 14 is a schematic representation of the factory reset confirmation interface according to this application;

fig. 15 – schematic representation of the interface of the reset process to factory settings according to this application;

fig. 16 is a schematic representation of the method of using the recovery key in the factory reset scenario according to this application;

fig. 17 is a schematic representation of the account verification interface according to this application;

fig. 18 is a schematic representation of the condition for changing the storage of ciphertext in the storage area in the factory reset scenario according to this application;

fig. 19 is a schematic representation of a device for storing ciphertext according to this application; And

fig. 20 is a diagram of an electronic device for storing ciphertext according to this application.

Detailed Description of the Invention

The following is a description of the technical solutions presented in the embodiments of the present application with reference to the accompanying drawings.

In fig. 1 shows a hardware system applicable to an apparatus according to the present application.

The device 100 may be a mobile phone, a smart screen, a tablet computer, a wearable electronic device, an on-board electronic device, an augmented reality (AR) device, a virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (ultra- mobile personal computer (UMPC), netbook, personal digital assistant (PDA), projector, etc. In this embodiment of the present application, the specific type of device 100 is not limited.

The device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging control module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2 , mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset jack 170D, sensor module 180, key 190, motor 191, indicator 192, camera 193, display 194, and card interface 195 subscriber identification module (SIM), etc. The sensor module 180 may include a pressure sensor 180A, a gyroscopic sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, an optical proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, ambient light sensor 180L, bone conduction sensor 180M, etc.

It should be noted that the structure shown in FIG. 1 does not particularly limit the device 100. In some other embodiments of the present application, the device 100 may include more or fewer components than those shown in FIG. 1, or device 100 may include a combination of some of the components shown in FIG. 1, or device 100 may include subcomponents of some of the components shown in FIG. 1. The components shown in FIG. 1 may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processors. For example, processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital digital signal processor (DSP), baseband processor and neural-network processing unit (NPU).

The various processing units may be independent devices or may be integrated devices.

The controller may generate an operation control signal based on the instruction operation code and the timing signal to complete control of instruction fetch and instruction execution.

The processor 110 may be further provided with memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache. The memory may store instructions or data recently used or cyclically used by the processor 110. If the processor 110 needs to use the instructions or data again, the instructions or data may be directly recalled from the memory. Repeated access is prevented and the latency of the processor 110 is reduced, thereby increasing system efficiency.

In some embodiments, processor 110 may include one or more interfaces. For example, processor 110 may include at least one of the following interfaces: an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code interface modulation, PCM), universal asynchronous receiver/transmitter interface (UART), mobile industry processor interface (MIPI), general-purpose input/output interface (GPIO) , SIM interface and USB interface.

The I2C interface is a bidirectional clocked serial bus and includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, processor 110 may include multiple groups of I2C buses. The processor 110 may be separately connected to a touch sensor 180K, a charger, a flash, a camera 193, or the like. using various I2C bus interfaces. For example, the processor 110 may be connected to the touch sensor 180K using an I2C interface such that the processor 110 communicates with the touch sensor 180K using the I2C bus interface to implement the touch function of the electronic device 100.

The I2S interface may be configured to perform audio communication. In some embodiments, processor 110 may include multiple groups of I2S buses. Processor 110 may be coupled to audio module 170 using an I2S bus to enable communication between processor 110 and audio module 170. In some embodiments, audio module 170 may transmit audio to wireless module 160 using an I2S interface to implement headset call answering functionality. Bluetooth.

The PCM interface can also be used for audio communication and analog signal sampling, quantization and encoding. In some embodiments, audio module 170 may be coupled to wireless module 160 using a PCM bus interface. In some embodiments, audio module 170 may alternatively transmit audio to wireless module 160 using a PCM interface to implement call answering functionality using a Bluetooth headset. Both the I2S interface and the PCM interface can be configured to perform audio communications.

The UART interface is a universal serial data bus and is configured for asynchronous communication. The bus may be a two-way communication bus. The bus converts the data to be transmitted between serial and parallel communications. In some embodiments, a UART interface is typically configured to connect the processor 110 and the wireless communication module 160. For example, processor 110 communicates with the Bluetooth module in wireless communication module 160 using a UART interface to implement Bluetooth functionality. In some embodiments, audio module 170 may transmit an audio signal to wireless module 160 using a UART interface to enable music playback functionality using a Bluetooth headset.

The MIPI interface may be configured to connect the processor 110 to a peripheral component, such as a display 194 or a camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. .P. In some embodiments, processor 110 communicates with camera 193 using a CSI interface to implement a photographing function of electronic device 100. Processor 110 communicates with display 194 using a DSI interface to implement a display function of electronic device 100.

The GPIO interface can be configured using software. The GPIO interface can be configured as a control signal interface or a data signal interface. In some embodiments, the GPIO interface may be configured to connect the processor 110 to the camera 193, display 194, wireless module 160, audio module 170, and sensor module 180. Alternatively, the GPIO interface can be configured as an I2C interface, I2S interface, UART interface, or MIPI interface.

The USB interface 130 is an interface that conforms to the USB standard specification, for example, may be a Mini USB interface, a Micro USB interface, or a USB Type C interface. The USB interface 130 may be configured to connect to a charger to charge the device 100, transfer data between the device 100 and a peripheral device, or connect to a headset to play audio using the headset. The USB interface 130 may further be configured to connect to another device 100, such as an AR device.

The connection relationship between the modules shown in FIG. 1 is merely an example for description and is not a limitation on the connection relationship between modules of the device 100. If necessary, the modules of the device 100 may alternatively use a combination of the plurality of connection methods presented in the above embodiment.

The charging control module 140 is configured to receive electrical power from the charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging control module 140 may receive current from a wired charger using the USB interface 130 . In some wireless charging embodiments, the charging control module 140 may receive an electromagnetic wave (current path shown in dashed line) using the wireless charging coil of the device 100. In addition to charging the battery 142, the charging control module 140 may further supply power to the device 100 using the module 141 power management.

The power management module 141 is configured to connect the battery 142, the charging control module 140, and the processor 110. The power management module 141 receives an input signal from the battery 142 and/or an input signal from the charging control module 140 and supplies power to the processor 110, internal memory 121, display 194, camera 193, wireless communication module 160, and the like. The power management module 141 may be further configured to monitor parameters such as battery capacity, number of battery recharge cycles, and battery health status (eg, leakage or impedance). If desired, the power management module 141 may be located in the processor 110, or the power management module 141 and the charging control module 140 may be located in the same device.

The wireless communication function of the device 100 may be implemented using devices such as antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

Antenna 1 and antenna 2 are configured to transmit and receive electromagnetic wave signals. Each antenna in device 100 may be configured to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve their use. For example, antenna 1 may be multiplexed into a wireless LAN diversity antenna. In some other embodiments, the antenna may be used in combination with a tuning switch.

The mobile communication module 150 may provide a solution that is applicable to wireless communication in the device 100, for example, at least one of the following solutions: a second generation ( ^2nd generation, 2G) mobile communication solution, a third generation (3rd ^generation) mobile communication solution generation 3G), a solution for fourth generation mobile communications (4 ^th generation, 4G) and a solution for 5th generation mobile communications (5 ^th generation, 5G). Mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), and the like. The mobile communication unit 150 may receive an electromagnetic wave using the antenna 1, perform processing such as filtering and amplifying the received electromagnetic wave, and then transmit the electromagnetic wave to a modem processor for demodulation. The mobile communication module 150 may further amplify the signal that is modulated by the modem processor and convert the signal into an electromagnetic wave for radiation using antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be located in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be located in the processor 110. In embodiments, at least some of the functional modules of the mobile communication module 150 may be located in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is configured to modulate the low-frequency modulating signal to be transmitted into a mid-frequency or high-frequency signal. The demodulator is configured to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the low-frequency baseband signal resulting from demodulation to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then sent to the application processor. The application processor outputs an audio signal using an audio device (eg, speaker 170A, receiver 170B) or displays an image or video using a display 194. In some embodiments, the modem processor may be an independent device. In some other embodiments, the modem processor may be independent of the processor 110 and located in the same device as the mobile communication module 150 or other functional module.

Similar to the mobile communication module 150, the wireless communication module 160 may also provide a wireless communication solution that applies to the device 100, such as at least one of wireless local area networks (WLAN), Bluetooth (BT) ), Bluetooth low energy (BLE), ultra wide band (UWB), global navigation satellite system (GNSS), frequency modulation (FM), near field communications (near field communication, NFC) and infrared (IR) technology. The wireless communication module 160 may be one or more devices integrating at least one communication processor module. The wireless communication module 160 receives the electromagnetic wave using the antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to the processor 110. The wireless communication module 160 may further receive the signal to be sent from the processor 110, perform frequency modulation and amplification signal and convert the signal into an electromagnetic wave for radiation using antenna 2.

In some embodiments, antenna 1 of device 100 is connected to mobile communication module 150, and antenna 2 of device 100 is connected to wireless communication module 160 so that electronic device 100 can communicate with a network and other electronic device using wireless communication technology. The wireless communication technology may include at least one of the following communication technologies: global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access channels (code division multiple access, CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long-term development ( long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, IR technology. GNSS may include at least one of the following positioning technologies: global positioning system (GPS), global navigation satellite system (GLONASS), BeiDou navigation satellite system (BDS) , quasi-zenith satellite system (QZSS) and satellite based augmentation systems (SBAS).

The device 100 may implement the display function using the GPU, display 194, and application processor. The GPU is an image processing microprocessor that is coupled to the display 194 and application processor. The GPU is configured to perform mathematical and geometric calculations to render graphics. Processor 110 may include one or more graphics processors that execute software instructions to generate or modify display information.

The display 194 may be configured to display an image or video. Display 194 includes a display panel. The display panel can use liquid crystal display (LCD), organic light-emitting diode (OLED), active-matrix organic light-emitting diode (AMOLED), flexible LED (flex LED, FLED), mini LED (mini LED, Mini LED), micro LED (micro LED, Micro LED), micro OLED (Micro OLED) or quantum dot LED (Quantum Dot Light-Emitting Diods, QLED). In some embodiments, device 100 may include one or N displays 194, where N is a positive integer greater than 1.

The device 100 may implement a shooting function using an ISP, camera 193, video codec, GPU, display 194, application processor, or the like.

The ISP is configured to process data returned by the camera 193. For example, when a photograph is taken, the shutter is pressed, light is transmitted to the camera photosensitive element using the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing, so that the electrical signal is converted into an image visible to the naked eye. The ISP can perform algorithm optimization on the noise point, brightness and color of the image, and the ISP can further optimize parameters such as exposure and color temperature of the shooting scenario. In some embodiments, the ISP may be located in camera 193.

Camera 193 is configured to capture a still image or video. An optical image of an object is generated using a lens and projected onto a photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a phototransistor based on a complementary metal-oxide semiconductor (CMOS). The photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the ISP. The ISP converts the electrical signal into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into a standard image signal in a format such as red green blue (RGB) or YUV. In some embodiments, device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

The digital signal processor is configured to process the digital signal. In addition to processing the digital image signal, the digital signal processor may additionally process another digital signal. For example, when device 100 selects a frequency, the digital signal processor is configured to perform a Fourier transform or the like. by frequency energy.

The video codec is designed to compress or decompress digital video. Device 100 may support one or more types of video codecs. Thus, device 100 can play back or record video in a variety of encoding formats, such as moving picture experts group (MPEG) 1, MPEG 2, MPEG 3, and MPEG 4.

The NPU is a processor used to access a biological neural network structure. For example, the NPU quickly processes input information by accessing the transmission mode between neurons in the human brain, and can additionally perform self-learning continuously. Functions such as intelligent recognition devices 100 may be implemented using the NPU, such as image recognition, face recognition, speech recognition, and text understanding.

The external memory interface 120 may be configured to connect to an external memory card, such as a secure digital (SD) card, to enhance the storage capabilities of the device 100. The external memory card communicates with the processor 110 using the external memory interface 120 to implement data storage function. For example, files such as music or videos are stored on an external memory card.

The internal memory 121 may be configured to store computer-executable program code, where the executable program code includes instructions. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store an operating system and an application requested by at least one function (eg, a voice playback function or an image playback function). The data storage area may store data (such as audio data or a phone book) created during use of the device 100. In addition, internal memory 121 may include high-speed random access memory and may further include non-volatile memory such such as at least one magnetic disk storage device, flash memory device, or universal flash storage (UFS). The processor 110 performs various processing methods on the device 100 by executing instructions stored in internal memory 121 and/or instructions stored in memory located in the processor.

The device 100 may implement an audio function, such as playing and recording music, using an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset jack 170D, an application processor, and the like.

Audio module 170 is configured to convert digital audio information to an analog output audio signal, and may also be configured to convert an analog input audio signal to a digital audio signal. Audio module 170 may be further configured to encode and decode audio signals. In some embodiments, audio module 170 or certain functional modules of audio module 170 may be located in processor 110.

The speaker 170A is also referred to as a horn and is configured to convert an electrical audio signal into an audio signal. The device 100 can listen to music or listen to a hands-free call using speaker 170A.

The receiver 170B is also called a handset and is configured to convert an electrical audio signal into an audio signal. When the user answers a call or listens to audio information using the device 100, the receiver 170B may be placed next to the ear to listen to the voice.

The microphone 170C is also called a speaker and is configured to convert an audio signal into an electrical signal. When making a call or sending voice information, the user can make sound near the microphone 170C to input an audio signal into the microphone 170C. At least one microphone 170C may be located in the device 100. In some other embodiments, two microphones 170C may be located in the device 100 to provide noise reduction functionality. In some other embodiments, three, four, or more microphones 170C may alternatively be located within device 100 to provide functions such as audio source identification and directional recording. Processor 110 may process the electrical signal output by microphone 170C. For example, audio module 170 and wireless module 160 may be connected using a PCM interface. After converting the ambient sound into an electrical signal (eg, a PCM signal), microphone 170C transmits the electrical signal to processor 110 using the PCM interface. Processor 110 performs loudness analysis and frequency analysis of the electrical signal to determine the loudness and frequency of ambient sound.

The 170D headset jack is designed to connect to a wired headset. The headset jack 170D may be a USB interface 130 or may be a standard 3.5 mm open mobile terminal platform (OMTP) interface 100 or a standard cellular telecommunications industry association of the USA (CTIA) interface ).

The pressure sensor 180A is configured to sense a pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be located on the display 194. There are many types of pressure sensors 180A, such as a resistive pressure sensor, an inductive pressure sensor, or a capacitive pressure sensor. The capacitive pressure sensor may include at least two parallel plates of conductive materials. When a force is applied to the pressure sensor 180A, the capacitance between the electrodes changes, and the device 100 determines the pressure force based on the change in capacitance. When a touch operation is performed on the display 194, the device 100 determines the intensity of the touch operation using the pressure sensor 180A. The device 100 may also calculate the location of the touch based on the detection signal of the pressure sensor 180A. In some embodiments, touch operations that are performed at the same touch location but have different intensities of touch operations may correspond to different operating instructions. For example, when a touch operation whose touch operation intensity is less than the first touch threshold is performed on the SMS messaging application icon, an instruction for viewing the SMS message is executed; or, when a touch operation whose touch operation intensity is greater than or equal to the first pressure threshold value is performed on the SMS messaging application icon, an instruction for creating a new SMS message is executed.

The gyro sensor 180B may be configured to determine the motion position of the device 100. In some embodiments, the angular velocities of the device 100 about three axes (namely, the x-axis, the y-axis, and the z-axis) may be determined using the gyro sensor 180B. The gyroscopic sensor 180B may be configured to implement image stabilization during shooting. For example, when the shutter button is pressed, the gyroscopic sensor 180B detects the angle of shake of the device 100 and, based on this angle, calculates the distance that the lens module should compensate, and allows the lens to eliminate the shake of the device 100 through reverse movement to realize image stabilization. The 180B gyro sensor can be further used in scenarios such as navigation and somatic games.

The barometric pressure sensor 180C is configured to measure barometric pressure. In some embodiments, device 100 calculates altitude based on the barometric pressure value that is measured by barometric pressure sensor 180C to assist with positioning and navigation.

The 180D magnetic sensor includes a Hall sensor. The device 100 can detect the opening and closing of the flip case using the magnetic sensor 180D. In some embodiments, when the device 100 is a flip phone, the device 100 may detect the opening and closing of the flip cover based on the magnetic sensor 180D. The device 100 may set a function such as automatically unlocking the flip flap based on a detected case open/close state or a detected flap open/close state.

Acceleration sensor 180E can detect the magnitude of accelerations of device 100 in all directions (typically x-axis, y-axis, and z-axis). When the device 100 is stationary, the magnitude and direction of gravity can be determined. The acceleration sensor 180E may be further configured to detect the position of the device 100 as an application input, such as switching between a landscape screen and a portrait screen or a pedometer.

The distance sensor 180F is configured to measure distance. The device 100 can measure distance using infrared or laser light. In some embodiments, such as in a shooting scenario, device 100 may use distance sensor 180F to measure distance to achieve rapid focusing.

The optical proximity sensor 180G may include, for example, a light-emitting diode (LED) and an optical detector such as a photodiode. The LED may be an infrared LED. The device 100 emits infrared light outward using an LED. The device 100 detects reflected infrared light from a nearby object using a photodiode. By detecting reflected light, device 100 can determine that an object is nearby. When the reflected light is not detected, the device 100 can determine that there is no object nearby. The device 100 can detect, using the optical proximity sensor 180G, whether the user is holding the portable device 100 close to the ear to automatically turn off the screen to save power. The 180G optical proximity sensor can also be used for auto unlock and auto lock in case mode or pocket mode.

The ambient light sensor 180L is configured to detect the brightness of the ambient light. The device 100 may adaptively adjust the brightness of the display 194 based on the measured ambient light brightness. The ambient light sensor 180L may also be configured to automatically adjust the white balance during photography. The ambient light sensor 180L may further cooperate with the optical proximity sensor 180G to detect whether the device 100 is in a pocket to avoid accidental touching.

The fingerprint sensor 180H is configured to collect fingerprints. The device 100 may use the collected fingerprint property to perform functions such as unlocking, accessing an application lock, taking a photo, and answering a call.

The temperature sensor 180J is configured to detect temperature. In some embodiments, device 100 implements a temperature processing policy based on the temperature that is detected by temperature sensor 180J. For example, when the temperature reported by temperature sensor 180J exceeds a threshold value, device 100 reduces the performance of a processor located adjacent to temperature sensor 180J to reduce power consumption and implement thermal protection. In some other embodiments, when the temperature is below another threshold, device 100 heats battery 142 to prevent device 100 from shutting down due to low temperature. In some other embodiments, when the temperature is below another threshold value, the device 100 increases the output voltage of the battery 142 to avoid a low temperature shutdown.

The 180K touch sensor is also referred to as a touch device. The touch sensor 180K may be located on the display 194. The touch sensor 180K and the display 194 form a touch screen, and the touch screen is also referred to as a touch screen. The touch sensor 180K is configured to detect a touch performed on or adjacent to the touch sensor 180K. The touch sensor 180K may transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation may be provided using the display 194. In some other embodiments, the touch sensor 180K may also be located on the surface of the device 100 in a position different from the position of the display 194.

The 180M bone conduction sensor can receive vibration signal. In some embodiments, the bone conduction sensor 180M may receive a vibration signal from the bone of a portion of a person's vocal cords. The 180M bone conduction sensor can also contact the body's pulse to receive the blood pressure beating signal. In some embodiments, the bone conduction sensor 180M may alternatively be located in the headset to provide a bone conduction headset. The audio module 170 may obtain a speech signal by parsing the vibration signal obtained by the bone conduction sensor 180M from the vibration of the bone mass of the vocal cord portion to realize a speech function. The application processor can analyze the heart rate information based on the blood pressure and pulse signal received by the 180M bone conduction sensor to realize the heart rate detection function.

The key 190 includes a power key and a volume key. Key 190 can be mechanical or touch. The device 100 may receive a key input signal to implement a function that is related to the key input signal.

The motor 191 may generate vibration. Motor 191 may be configured to provide a prompt for an incoming call or may be configured to provide touch feedback. Motor 191 may generate different vibration feedback effects for different touch operations performed in different applications. For touch operations performed on different areas of the display 194, the motor 191 may also generate various vibration feedback effects. Different application scenarios (e.g., time reminder, information, alarm, game) may correspond to different vibration feedback effects. The touch vibration feedback effect can be further customized.

The indicator 192 may be an indicator light and may be configured to indicate charging status and power changes, or may be configured to indicate a message, missed call, and notification.

The SIM card interface 195 is configured to connect to a SIM card. The SIM card may be inserted into the SIM card interface 195 to communicate with the device 100, or may be removed from the SIM card interface 195 to effect separation from the device 100. The device 100 may support one or N SIM card interfaces, where N is a positive integer greater than 1. Multiple cards can be simultaneously inserted into the same SIM card interface 195. The types of multiple cards may be the same or different. The SIM card interface 195 may also be compatible with an external memory card. The device 100 communicates with the network using a SIM card to implement functions such as calling and data transfer. In some embodiments, device 100 uses an embedded SIM card (embedded-SIM, eSIM). The eSIM card may be embedded in the device 100 and cannot be separated from the device 100.

The hardware system of the device 100 has been described in detail above. The following is a description of the software system of the device 100. The software system may use a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. In this embodiment of the present application, a layered architecture is used as an example to describe the software system of the device 100.

As shown in FIG. 2, a software system using layered architecture is divided into several layers, and each layer has a clear role and task. The levels interact with each other using a software interface. In some embodiments, the Android system is divided into four layers: the application layer, the application infrastructure layer, the Android runtime and system library, and the kernel layer from top to bottom.

The application layer may include applications such as Camera, Gallery, Calendar, Phone, Maps, Navigation, WLAN, Bluetooth, Music, Video, and "Message exchange".

The application infrastructure layer provides the application programming interface (API) and programming framework for the application at the application level. The application infrastructure layer may include some specified functionality.

For example, the application infrastructure layer includes a window manager, a content provider, a browsing system, a phone manager, a resource manager, and a notification manager.

The window manager is configured to manage a window program. The window manager can get the display size, determine whether there is a status bar, lock the screen, take a screenshot, and so on.

The content provider is used to store and retrieve data and provide access to data through the application. The data may include video, image, audio, calls made and received, browsing history and bookmarks, address book, etc.

The viewing system includes visual controls such as a control for displaying text and a control for displaying an image. The browsing system may be configured to build an application. The display interface may include one or more views, for example, include an SMS message notification icon display interface and may include a view for displaying text and a view for displaying an image.

The telephone manager is configured to provide a communication function for the device 100, such as managing the status of a call (including answering or rejecting).

The resource manager provides various resources for the application, such as a localized string, icon, image, layout file, and video file.

Notification Manager allows an application to display notification information in the status bar, which can be used to convey a notification type message and can automatically disappear after a short stay without requiring user intervention. For example, the notification manager is configured to provide a download completion notification and send a message notification. The notification manager can also manage the notification that appears on the top system status bar as a graphic or scroll bar text, such as a notification about an app running in the background. The notification manager can also manage the notification that appears on the display as a dialog box. For example, the status bar prompts for text information, plays a notification sound, vibrates the electronic device, or flashes an indicator light.

The Android runtime includes a core library and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

The core library includes two parts: a function that needs to be called in Java, and a core Android library.

The application layer and the application infrastructure layer run on a virtual machine. The virtual machine executes Java files at the application level and at the application infrastructure level as binary files. The virtual machine is used to implement functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

The system library may include many functional modules, for example, a surface manager, a media library (Media Libraries), a 3D graphics processing library (for example, open graphics library for embedded systems, OpenGL ES ) and a 2D graphics engine (for example, the skia graphics library (SGL)).

The surface manager is configured to: manage the display subsystem and combine 2D and 3D layers for a variety of applications.

The media library supports playback and recording of audio in multiple formats, playback and recording of video in multiple formats, and still image files. The media library can support multiple audio and video encoding formats such as MPEG 4, H.264, moving picture experts group audio layer III (MP3), advanced audio coding (AAC) ), adaptive multi-rate (AMR), joint photographic experts group (JPG), and portable network graphics (PNG).

The 3D graphics processing library may be configured to implement 3D graphics drawing, image rendering, layout, and level processing.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is the layer between hardware and software. The kernel layer may include driver modules such as a display driver, a camera driver, an audio driver, and a sensor driver.

Next, a description will be given of an example operating procedure of the software system and the hardware system of the device 100 with reference to displaying a photographing scenario.

When the user performs a touch operation on the 180K touch sensor, a corresponding hardware interrupt is sent to the kernel level. The kernel layer processes the touch operation into a raw input event, and the raw input event includes information such as the touch coordinates and the timestamp of the touch operation. The unhandled input event is stored at the kernel level. The application infrastructure layer receives the raw input event from the kernel layer, identifies the control corresponding to the raw input event, and notifies the application (APP) corresponding to the control. For example, a touch operation is a tapping operation, and the application corresponding to the control is a camera application. After the camera application is awakened by a touch operation, the kernel-level camera driver can be called using the API, and the camera driver controls the camera 193 to take photographs.

Below, the device 100 is used as an example to describe a method for storing ciphertext according to the present application.

To ensure the security of files in the external memory, files in the external memory can be encrypted, and then stored in the external memory, and keys for decrypting the files are stored in the internal memory of the device 100. Thus, the contents of the external memory can be read in the device 100 only as plaintext . When the external memory is connected to another electronic device, since the other electronic device does not store the key, the contents of the external memory cannot be decrypted by the other electronic device, which ensures the security of the files in the external memory.

External memory can be an SD card, USB flash drive, or other type of memory. The external memory may establish a data connection with the device 100 in an insertion manner, or may establish a data connection with the device 100 in a wired or wireless manner. The specific type of external memory and the method of connecting the external memory and the device 100 are not limited in the present application. Below, SD is used for description as an example.

The user can initiate the SD card encryption process in the encryption setting interface shown in FIG. 3. The user can click "memory card encryption" (Fig. 3) to enter the encryption settings confirmation interface shown in Fig. 4. Then the user clicks “memory card encryption” (Fig. 4) to ensure that the file on the SD card is encrypted. The encryption processing interface is shown in FIG. 5. The encryption algorithm that is used in the encryption process is not limited in this application.

After the file on the SD card is encrypted, you need to properly save the file encryption key (FEK). The way to store a FEK is to encrypt the FEK multiple times and then store the FEK in an erasable partition. The method is shown in Fig. 6.

After the user initiates the SD card encryption process in the encryption setting interface shown in FIG. 3, the SD card encryption setting module generates an encryption instruction. Depending on the lock screen password setting condition, there are two cases for the module called by the encryption instruction.

Case 1: The lock screen password is not set.

The SD card encryption module calls the encryption control module (Vold) with the encryption instruction to encrypt the FEK. If the user has not set a password for the lock screen, the default value can then be used to encrypt the file encryption key (FEKEK). The following describes the FEK encryption process in detail.

Case 2: Screen lock password is set.

The SD card encryption module calls the LockSettingsService service (LockSettingsService) using the encryption instruction to obtain the hash value of the password. The LockSettingsService then passes the password hash value to the encryption management module (Vold) so that the password hash value is later used to encrypt the file encryption key. The password hash value is information generated from the lock screen password. For example, the LockSettingsService service performs a lock screen password hash calculation when the user sets a lock screen password to generate a password hash value, retrieves a previously stored password hash value after the user initiates SD card encryption, and passes the password hash value to encryption control module.

Vold is responsible for implementing basic encryption and decryption functions. Vold runs the encryption logic or decryption logic for the SD card by calling the encryption library or decryption library.

When a file system (such as eCryptfs) creates a file on an SD card, the file system generates a random number for each file. For example, when eCryptfs creates a new file, a random function provided by the kernel produces a random number. The random number is FEK. FEK is used to encrypt the file on the SD card and to decrypt the encrypted file on the SD card.

Optionally, eCryptfs stores the encrypted file in an open pretty good privacy (OpenPGP) file format. The encrypted file can be divided into many logical blocks (extent), and the size of each logical block can be adjusted. However, the size of each logical block is usually no larger than the size of the physical page.

Once the file on the SD card is encrypted, you need to encrypt and save the FEK. When a user sets SD card encryption, Vold unmounts and then remounts the file system. In this case, a random number is generated. The random number is FEKEK (an example of the first key). FEKEK is used for FEK encryption (second key example), where FEKEK is set by Vold to the kernel keyring, and the filesystem receives FEKEK from the keyring when encrypting FEK. The encrypted FEK is stored in the meta data of the encrypted file.

Once the FEK is encrypted, the FEKEK must also be encrypted and stored. Since Vold is a rich execution environment (REE) module and the security is not compliant, FEKEK cannot be encrypted. Vold can call the key management module in a trust execution environment (TEE) using a client application (CA), that is, a key master trust application (TA), and the key master TA completes the encryption on FEKEK.

The key master TA can use the hash of the password and encrypt FEKEK according to the advanced encryption standard (AES) to generate ciphertext 1 (an example of the fifth ciphertext). The keymaster TA can then use the hardware unique key (HUK) and encrypt the password hash according to AES to generate the keymaster_key_blob (sixth ciphertext example). The key master TA stores ciphertext 1 and keymaster_key_blob in the erasable partition (/data path).

Since the HUKs of different devices are unique, the password hashes are encrypted using the HUK to ensure that the aforementioned keymaster_key_blob can only be decrypted on the device 100 to ensure the security of the encrypted file on the SD card.

The encryption procedure related to FIG. 6 is shown in FIG. 7.

If there are two files to be encrypted (file 1 and file 2) on the current SD card, the file system generates two random numbers, namely FEK1 and FEK2, for the two files. The file system then uses FEK1 to encrypt file 1 and uses FEK2 to encrypt file 2.

After encryption of file 1 and file 2 is complete, the file system obtains FEKEK from the key set and separately encrypts FEK1 and FEK2 using FEKEK. The encrypted FEK1 is stored in the metadata of file 1, and the encrypted FEK2 is stored in the metadata of file 2.

Vold then calls the key master TA using the CA, and the key master TA encrypts the FEKEK using the hash value of the password. The key master TA then encrypts the hash value of the password using a hardware HUK.

When the encryption file on the SD card needs to be decrypted, the device 100 performs the reverse process of the encryption procedure shown in FIG. 7. For example, Vold calls the keymaster TA using the CA to perform the following decryption step: the keymaster TA obtains the keymaster_key_blob and ciphertext 1 from the erased partition, first decrypts the keymaster_key_blob with HUK to obtain the hash value of the password, and then decrypts ciphertext 1. using the hash value of the password to get FEKEK. After receiving the FEKEK from the TA keymaster, Vold installs the FEKEK in the keyring. The file system receives the FEKEK from the key set, decrypts the FEK, and then decrypts the decrypted file on the SD card using the FEK.

For example, when eCryptfs opens an encrypted file, eCryptfs reads the encrypted file's header metadata using the lower-level file system and delivers the metadata to the key store module (including the key master TA module); the key store module receives the FEKEK from the key set and decrypts the encrypted FEK in the metadata, using the FEKEK to generate the FEK; and then eCryptfs decrypts the encrypted file using FEK. When decrypting an encrypted file, each logical block (extent) of the encrypted file is read into the page cache and decrypted using the Kernel Crypto API.

When the device 100 performs the first type of reset (also called a “custom reset,” that is, the user resets the device 100 from the system setup menu), the data in the erase area is cleared. In this case, device 100 may back up ciphertext 1 and keymaster_key_blob so that the files on the SD card cannot be decrypted because ciphertext 1 and keymaster_key_blob have been deleted. The user reset backup procedure is shown in FIG. 8.

The user controls, using a setup interface, the device 100 to restore factory settings. The device 100 verifies the lock screen password that is entered by the user. For example, device 100 computes a lock screen password that is entered by the user to obtain a password hash value, and then compares the password hash value obtained by the calculation with the stored password hash value. If two password hashes match, it is determined that the two password hashes have been verified.

After verification, the application's framework layer sends a broadcast message to restore factory settings. After receiving the broadcast message, Vold starts the key backup procedure, calls the key master TA using the CA to decrypt the FEKEK from the erased partition, and then encrypts the FEKEK using the default value and encrypts the default value using the HUK. The encrypted FEKEK and the default value (an example of the seventh ciphertext and eighth ciphertext) are stored in the non-erasable partition.

As used herein, a non-erasable partition refers to a storage area in which data is not erased during a second type of reset (which is also called a “factory reset,” i.e., the user does not reset the device 100 using the system setup menu). The non-erasable partition can be /sec_storage and can be another protected storage area in the TEE, such as a replay protected memory block (RPMB).

After a factory reset and restart, device 100 determines whether the SD card is in the correct location. When the SD is in the correct location, the TA key master copies the encrypted FEKEK and default value from the non-erasable partition to the erasable partition so that the encrypted FEKEK and default value can be used to recover the FEK and decrypt the file in the SD card.

Finally, before and after the device 100 performs a user reset, a key change condition that is stored in the storage area is shown in FIG. 9.

After the user instructs the device 100 to perform a user reset, the device 100 is initiated to perform a key backup. During the backup phase, the keys ciphertext 1 and keymaster_key_blob are stored in the erased partition. Ciphertext 1 and keymaster_key_blob are decrypted and encrypted and stored in the non-erasable partition as "FEKEK encrypted with default and default encrypted with HUK."

Once the key backup is complete, the device 100 enters a formatting phase. During the formatting phase, the data in the erasable partition is cleared, and the data in the non-erasable partition is preserved.

Once formatting is complete, device 100 proceeds to the key recovery stage. During the key recovery phase, the ciphertext in the non-erasable partition (FEKEK encrypted with the default value and the default value encrypted with HUK) is copied to the erased partition, thereby completing key recovery.

In the above user reset process, the user needs to format the device 100 using the system setup menu. The device 100 has the ability to back up the ciphertext (encrypted FEKEK) in an erasable partition so that the file on the SD card can still be decrypted after the device 100 is formatted. However, when the user performs a second type of reset (such as a factory reset) on device 100 without using the system setup menu, the ciphertext in the erasable partition is deleted without being copied to the non-erasable partition, and thus the file on the formatted SD card of device 100 cannot be decrypted.

Next, a description will be given of another embodiment of a method for storing ciphertext according to the present application, so that a file on the SD card of the device 100 after a factory reset can still be decrypted. This embodiment may be applied to device 100 together with the previous "user reset" embodiment or may be applied to device 100 separately.

After the user starts encryption on the SD card in the setting interface shown in FIG. 3, the device 100 performs the key backup procedure shown in FIG. 10. As shown in FIG. 10, the SD card encryption setting module calls the account login module using the encryption instruction to perform subsequent processing. Depending on the account login condition, there are two ways to handle the account login module:

Case 3: The user is not logged in with an account.

The account login module displays an account login interface as shown in FIG. 11 to prompt the user to sign in with an account (for example, sign in with an Honor account). After successfully logging in with an account, the Account Login module calculates the hash value of the account ID (ID) and then passes the hash value of the account ID to Vold.

Case 4: The user is logged in using an account.

The account login module obtains the hash value of the account ID and passes the hash value of the account ID to Vold. Optionally, if the account login module does not calculate the account ID hash value before the user initiates SD card encryption, the account login module calculates the account ID hash value when the user initiates SD card encryption; or, if the account login module calculates the account ID hash value before the user initiates SD card encryption, the account login module directly obtains the account ID hash value when the user initiates encryption SD cards.

After receiving the hash value of the account ID, Vold calls the key master TA using the CA, and the key master TA encrypts and backs up the FEKEK.

The key master TA can use the hash value of the account ID and encrypt FEKEK according to AES to generate ciphertext 2 (example first ciphertext). The keymaster TA can then use the HUK and encrypt the account ID hash value according to AES to generate keymaster_key_blob_bak (an example of a second ciphertext). The keymaster TA calls the TEE API to store ciphertext 2 and keymaster_key_blob_bak in a non-erasable partition (/sec_storage path), thereby completing the FEKEK backup.

Since the HUKs of different devices are unique, the account ID hash value is encrypted using the HUK to ensure that the aforementioned keymaster_key_blob_bak can only be decrypted on the device 100 to ensure the security of the encrypted file on the SD card.

In the method shown in FIG. 10, after the user initiates encryption on the SD card using the setup interface, the device 100 can backup the FEKEK at any time before performing a factory reset. Even if the device 100 then performs a factory reset, the device 100 can restore FEKEK after a restart, thereby solving the problem of the SD card being unable to decrypt a file after a factory reset.

If necessary, after the device 100 has performed the method shown in FIG. 10, if the user switches the registered account ID, Vold gets the hash value of the new account ID and updates ciphertext 2 and keymaster_key_blob_bak with the hash value of the new account ID. The update process is shown in Fig. 12.

The following describes the process in which the device 100 decrypts a file on the SD card after performing a factory reset.

The user first locks the screen (or turns off) the device 100, and then can press a key combination (for example, "Volume key" + "Power key") to allow the device 100 to enter recovery mode and display the factory reset setting interface shown in fig. 13. Then, the device 100 displays the confirmation interface shown in FIG. 14, after the user touches the inscription “restore factory settings”. After the user taps "restore factory settings" on the interface shown in FIG. 13, the device 100 performs a factory reset to display the factory reset interface shown in FIG. 15.

After the factory reset is completed, the device 100 restarts, launches the Power On Wizard program, and performs the key recovery procedure shown in FIG. 16.

The Power On Wizard calls the mobile phone finder to determine whether the factory reset protection (FRP) state has been activated. The mobile phone retrieval module using the anti-theft CA calls the anti-theft TA to determine whether the FRP state has been triggered. If the FRP state has been initiated, the mobile phone search module displays the account verification interface shown in FIG. 17. The account that is verified by the account verification interface is the account associated with the FRP state (that is, the last registered account before the device 100 performs a factory reset). After the user has entered the correct password on this interface, the mobile phone search module notifies that the Vold account has been successfully verified. Vold then calls the key master TA using the CA to perform the following steps to recover the key.

The keymaster TA obtains the keymaster_key_blob_bak and ciphertext 2 from the non-erasable partition, first decrypts the keymaster_key_blob_bak using the HUK to obtain the account ID hash value, and then decrypts the ciphertext 2 using the account ID hash value to obtain the FEKEK.

The key master TA re-encrypts FEKEK using the default value to generate the third ciphertext and uses HUK to encrypt the default value to generate the fourth ciphertext. The encrypted FEKEK and the default value are stored in the non-erasable partition (/sec_storage path) as backup keys. The keymaster TA then copies the encrypted FEKEK and default value to the erasable partition (/data path) to use when encrypting or decrypting the file on the SD card. The old lock screen password is deleted after the device 100 performs a factory reset. In the previous embodiment, the device 100 can decrypt the SD card using the default value as a key when a new screen lock password is not set.

If necessary, the keymaster TA can encrypt FEKEK without using the default value and directly copy keymaster_key_blob_bak and ciphertext 2 from the non-erasable partition to the erasable partition. In this case, device 100 may prompt the user to set a new lock screen password to use the new lock screen password for FEKEK encryption.

When a file on the SD card needs to be encrypted, the keymaster TA decrypts the FEKEK from the erased partition and passes the FEKEK to the keyring using Vold. After encrypting a file on the SD card using FEK, the file system obtains the FEKEK from the key set, encrypts the FEK using the FEKEK, and stores the encrypted FEK as file metadata.

When a file on the SD card needs to be decrypted, the key master TA decrypts the FEKEK from the erased partition and passes the FEKEK to the keyring using Vold. The file system decrypts the FEK from the SD card file metadata using FEKEK and then decrypts the file using FEK.

Finally, before and after the device 100 performs a factory reset, a key change condition that is stored in the storage area is shown in FIG. 18.

When the user instructs the device 100 to encrypt a file on the SD card, the device 100 is triggered to perform a key backup. During the key backup phase, the erasable partition stores ciphertext 1 and keymaster_key_blob, and the non-erasable partition stores ciphertext 2 and keymaster_key_blob_bak. Ciphertext 1 is a FEKEK encrypted with a hash of the password, keymaster_key_blob is a hash of the password encrypted with a HUK, ciphertext 2 is a FEKEK encrypted with a hash of the account ID, and keymaster_key_blob_bak is a hash of the account ID , encrypted using HUK.

After the user instructs the device 100 to perform a factory reset, the device 100 enters the factory reset stage and performs a format. During the factory reset phase, the data in the erased partition is cleared and the data in the non-erased partition is retained.

Once formatting is complete, device 100 proceeds to the key recovery stage. During the key recovery stage, the ciphertext (ciphertext 2 and keymaster_key_blob_bak) in the non-erasable partition is decrypted, encrypted, and copied to the erased partition as "FEKEK encrypted with default and default encrypted with HUK", thereby completing key recovery .

An example of a method for storing ciphertext according to the present application has been described in detail above. It can be understood that in order to implement the above functions, a corresponding device includes a corresponding hardware structure and/or a software module that performs each function. It will be apparent to one skilled in the art that, with reference to the examples described in the embodiments disclosed herein, the blocks and steps of the algorithm may be implemented in hardware or a combination of hardware and computer software provided herein. Whether a function is implemented in hardware or in hardware controlled by computer software depends on the specific application and the design constraints of the solution. One skilled in the art may employ different methods to implement the described functionality for each particular application, but such implementation should not be considered beyond the scope of this application.

In the present application, the device for storing ciphertext can be divided into functional units based on the above example methods. For example, each function block can be obtained by dividing based on the corresponding function, or two or more functions can be combined into one block. The above integrated block may be implemented as hardware or may be implemented as a software functional block. It should be noted that the modular division in the present application is an example and is simply a logical division of functions, and other division method may be used during actual implementation.

In fig. 19 is a schematic diagram of the structure of an apparatus for storing ciphertext according to the present application. The device 1900 includes a processing unit 1910 and an input unit 1920.

The input unit 1920 is configured to receive an encryption instruction, where the encryption instruction instructs to encrypt a file in the external memory.

The processing unit 1910 is configured to: obtain its own value of the first account ID based on the encryption instruction; encrypting a first key using the first account identifier's own value to generate a first ciphertext, where the first key is used to encrypt the second key, and the second key is used to encrypt the first file in the external memory; encrypting the eigenvalue of the first account identifier to generate a second ciphertext; and storing the first ciphertext and the second ciphertext in an indelible section.

If necessary, the input unit 1920 is further configured to obtain pointer information for account switching.

The processing unit 1910 is further configured to: check the first account ID based on the indication information; obtaining its own value of the second account identifier after checking the first account identifier; and updating the first ciphertext and the second ciphertext based on the own value of the second account identifier.

If necessary, the processor 1910 is further configured to determine whether the FRP state is activated; checking the first account ID when initiating the FRP state; and, when the first account ID is verified successfully, decrypting the first ciphertext and the second ciphertext to generate the first key.

If necessary, processor 1910 is further configured to: encrypt the first key using a default value to generate a third ciphertext; default encryption to generate a fourth ciphertext; and storing the third ciphertext and the fourth ciphertext in an indelible section.

If necessary, the processing unit 1910 is further configured to: copy the third ciphertext and the fourth ciphertext from the non-erasable section to the erasable section; generating a first key based on the third ciphertext and the fourth ciphertext in the erased section; and decrypting the file in external memory based on the first key.

With regard to the specific manner in which the device 1900 performs the method of storing ciphertext, and the resulting beneficial effect, see the corresponding description of embodiments of the method.

In fig. 20 is a schematic diagram of the structure of an electronic device according to the present application. The dotted line in Fig. 20 indicates that the device or module is optional. The device 2000 may be configured to implement the method described in the previous method embodiments.

Apparatus 2000 includes one or more processors 2001. One or more processors 2001 may support apparatus 2000 to implement a method in embodiments of the method. Processor 2001 may be a general purpose processor or a special purpose processor. For example, processor 2001 may be a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). ) or other programmable logic device such as a discrete gate, transistor logic device, or discrete hardware component.

The processor 2001 may be configured to control the device 2000, execute a software program, and process software program data. The device 2000 may further include a communication unit 2005, which may be configured to input (receive) and output (transmit) a signal.

For example, device 2000 may be a chip, communication unit 2005 may be input circuitry and/or output circuitry of the chip, or communication unit 2005 may be a communication interface of the chip, and the chip may be used as an integral part of a terminal device or other electronic device.

As another example, device 2000 may be a terminal device, and communication unit 2005 may be a transceiver circuit of the terminal device, or communication unit 2005 may be transceiver circuitry of the terminal device.

The device 2000 may include one or more memory devices 2002. The program 2004 is stored in the memory 2002. The program 2004 may be executed by the processor 2001 to generate an instruction 2003 allowing the processor 2001 to execute, based on the instruction 2003, the method described in the above embodiments of the method. Memory 2002 can additionally store data as needed. If necessary, processor 2001 may additionally read data (eg, the first ciphertext and the second ciphertext) stored in memory 2002, where the data may be stored at the same memory location addresses as program 2004, or the data may be stored at different location addresses. memory, like the 2004 program.

The processor 2001 and memory 2002 may be located separately, or may be integrated together, for example, integrated into a system on chip (SOC) of a terminal device.

The present application further provides a computer program product. When the computer program product is executed by the processor 2001, the method according to any embodiment of the method presented in this application is implemented.

The computer program product may be stored in memory 2002, for example, may be program 2004, and program 2004 is finally converted into an executable target file that can be executed by processor 2001 after processing processes such as preprocessing, compilation, assembly, and linking.

The present application further provides a computer-readable storage medium. A computer-readable storage medium stores a computer program. When the computer program is executed by a computer, the method according to any embodiment of the method presented in this application is implemented. The computer program may be a program written in a high-level language or may be an executable target program.

For example, the computer-readable storage medium is memory 2002. Memory 2002 may be volatile memory or non-volatile memory, or memory 2002 may include both volatile memory and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable EPROM (electrically EPROM, EEPROM), or flash memory. Non-volatile memory can be random access memory (RAM) and used as an external cache. For example, but not by way of limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data SDRAM rate SDRAM, DDR SDRAM), enhanced SDRAM (enhanced SDRAM, ESDRAM), synchronous DRAM (synchlink DRAM, SLDRAM) and RAM with direct rambus RAM, DR RAM.

It should be clearly understood by one skilled in the art that for convenience and brevity in describing the detailed operating process and technical effect of the above-described hardware and apparatus, reference may be made to the corresponding process and technical effect in the above method embodiments, and the details are not repeated herein. are described.

In several embodiments presented herein, the disclosed system, apparatus, and method may be implemented in other ways. For example, certain features of the method embodiments described above may be ignored or not implemented. The described embodiment of the device is merely an example. The block division is simply a logical division of functions and may be a different division in the actual implementation. Multiple blocks or components can be combined or integrated into another system. In addition to this, connections between blocks or connections between components can be direct connections or indirect connections. Connections include connections in electronic, mechanical or other forms.

It should be understood that in various embodiments of the present application, the sequence numbers of the above-mentioned processes do not indicate the sequence of execution. The execution sequences of the processes should be determined based on the functions and internal logic of the processes and should not be construed as any limitation on the processes for implementing the embodiments of this application.

In addition, the terms "system" and "network" are often used interchangeably in this description. In this specification, the term "and/or" is used only to describe an association relationship between associated objects and indicates that three relationships may exist. For example, A and/or B can mean the following: only A exists, both A and B exist, and only B exists. In addition to this, the "/" symbol in this specification typically indicates an "or" relationship between associated objects .

In conclusion, the previous descriptions are merely preferred embodiments of the technical solutions of the present application and are not intended to limit the scope of protection of the present application. Any modifications, equivalents, modifications, etc. made in accordance with the spirit and principles of this application shall fall within the scope of protection of this application.

Claims (66)

1. A method for processing a file stored in an external memory, wherein the method is applied to an electronic device, wherein the electronic device includes an internal memory that includes an erasable section and a non-erasable section, and the electronic device is connected to the external memory, wherein the method comprises: displaying the external memory encryption configuration interface; receiving a first operation that is performed by the user at the encryption setting interface, wherein receiving the first operation that is performed by the user at the encryption setting interface comprises: receiving an encryption instruction, wherein the encryption instruction instructs to encrypt a first file stored in the external memory; encrypting a first file stored in the external memory using a second key in response to encryption instructions; obtaining the first account ID based on the encryption instruction; encrypting a first key based on the first account identifier to generate a first ciphertext, the first key being used to encrypt the second key; encrypting the first account identifier to generate a second ciphertext; And storing the first ciphertext and the second ciphertext in an indelible section; receiving a second user operation; displaying the factory reset setting interface in response to the second operation; receiving a third operation that is performed by the user in the factory settings interface; performing a factory reset in response to the third operation, in which the data in the erasable partition is deleted during the factory reset, and the data in the non-erasable partition is retained during the factory reset; displaying the account verification interface; receiving verification information that is input by the user in the account verification interface; And checking the first account ID based on the verification information when the first account ID is verified successfully, and, when an operation in which the user accesses the first file in the external memory is received, decrypting the first file encrypted in the external memory based on the first ciphertext, and a second ciphertext stored in an indelible partition. 2. The method according to claim 1, in which the first key encryption based on the first account ID contains: calling a key management module to encrypt the first key using a hash value of the first account ID; And The encryption of the first account ID contains: calling a key management module to encrypt a hash value of the first account ID; wherein storing the first ciphertext and the second ciphertext in an indelible section contains: calling the trusted execution environment application programming interface to store the first ciphertext and the second ciphertext in an indelible section. 3. The method according to claim 1, in which the method additionally contains: obtaining pointer information for account switching; checking the first account ID based on the index information; obtaining a second account ID after verifying the first account ID; And updating the first ciphertext and the second ciphertext based on the second account ID. 4. The method of claim 1, wherein before decrypting the encrypted first file that is encrypted in the external memory based on the first ciphertext and the second ciphertext stored in the indelible partition, the method further comprises: decrypting the first ciphertext and the second ciphertext to generate the first key, wherein the verification of the first account ID based on the verification information comprises: checking the first account ID based on the verification information when the factory reset protection FRP state is initiated. 5. Method according to any one of paragraphs. 1-4, in which the method further comprises: encrypting the first key using a default value to generate a third ciphertext; default encryption to generate fourth ciphertext; And storing the third ciphertext and the fourth ciphertext in an indelible section. 6. The method according to claim 5, in which the method additionally contains: copying the third ciphertext and the fourth ciphertext from the non-erasable section to the erasable section; generating a first key based on the third ciphertext and the fourth ciphertext in the erased section; And decryption based on the first key of the first file encrypted in external memory. 7. Method according to any one of paragraphs. 1-6, in which performing a factory reset in response to the third operation contains: receiving a factory reset instruction, which is initiated by the third operation in the factory reset setting interface; And formatting data in an erasable partition based on the factory reset instructions. 8. Method according to any one of paragraphs. 1-7, wherein the first key is further used to encrypt a third key and the third key is used to encrypt a second file that is encrypted in the external memory. 9. Method according to any one of paragraphs. 1-8, in which the method further comprises: obtaining the lock screen password based on the encryption instruction; encrypting a first key based on the lock screen password to generate a fifth ciphertext; encrypting the lock screen password to generate the sixth ciphertext; And storing the fifth ciphertext and the sixth ciphertext in the erasable partition, in which the first key encryption based on the lock screen password contains: calling the key management module to encrypt the first key using its own lock screen password value; And Lock screen password encryption contains: Calling the key management module to encrypt the hash value of the lock screen password. 10. The method according to claim 9, in which the method additionally contains: receiving a user reset instruction that is initiated by the configuration interface; And Backs up the fifth ciphertext and the sixth ciphertext to a non-erasable partition based on a user reset instruction. 11. The method of claim 10, wherein backing up the fifth ciphertext and the sixth ciphertext to an indelible partition based on the user reset instruction comprises: decrypting the first key from the fifth ciphertext and the sixth ciphertext based on the user reset instruction; encrypting the first key using a default value to generate a seventh ciphertext; default encryption to generate the eighth ciphertext; And storing the seventh ciphertext and the eighth ciphertext in an indelible section. 12. The method according to claim 11, in which the method additionally contains: copying the seventh ciphertext and the eighth ciphertext from the non-erasable partition to the erasable partition after the user reset is completed; decrypting a first key from the seventh ciphertext and the eighth ciphertext in the erased section; And decryption based on the first key of the first file encrypted in external memory. 13. A chip comprising a processor, wherein when the processor executes instructions, the processor executes the method of any one of claims. 1-12. 14. A computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor may perform the method of any one of claims. 1-12.

Images