Source: https://patents.google.com/patent/US20090307783A1/en
Timestamp: 2019-09-20 01:52:41
Document Index: 201680840

Matched Legal Cases: ['art 151', 'art 152', 'art 153', 'art 154', 'art 155', 'art 156', 'art 157', 'art 158']

US20090307783A1 - Data processing device, method, program, integrated circuit, and program generating device - Google Patents
Data processing device, method, program, integrated circuit, and program generating device Download PDF
US20090307783A1
US20090307783A1 US12/298,198 US29819807A US2009307783A1 US 20090307783 A1 US20090307783 A1 US 20090307783A1 US 29819807 A US29819807 A US 29819807A US 2009307783 A1 US2009307783 A1 US 2009307783A1
US12/298,198
2006-04-24 Priority to JP2006-118881 priority Critical
2006-04-24 Priority to JP2006118881 priority
2007-04-24 Application filed by Panasonic Corp filed Critical Panasonic Corp
2007-04-24 Priority to PCT/JP2007/058838 priority patent/WO2007125911A1/en
2008-11-06 Assigned to PANASONIC CORPORATION reassignment PANASONIC CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ITO, YOSHIKATSU, MAEDA, MANABU, MATSUSHIMA, HIDEKI
2009-12-10 Publication of US20090307783A1 publication Critical patent/US20090307783A1/en
FIG. 10 is a flowchart showing operations performed by the normal program 12 for completing use of a protected program 8 a;
FIG. 12 is a flowchart showing debugging of a protected program 8 a using the debugger 14 when a debug exception has caused due to a break point during execution of the protected program 8 a:
FIG. 1 schematically shows a data processing apparatus 1 pertaining to the first embodiment of the present invention. The data processing apparatus 1 includes an LSI 12 equipped with a protection mechanism, a switching mechanism 3, a protected OS 6, a debug function 7, a protected program 8 (8 a, 8 b, . . . ), a normal OS 11, a normal program 12 (12 a, 12 b, . . . ), a switching device driver 13 (hereinafter called the “switching driver 13”), a debugger 14, and a switching device driver 15 fcr the debugger (hereinafter called the “debugger switching driver 15”).
Explanations for Each Function Block of the First Embodiment 1.1.1 LSI 2
The normal program 12 (12 a, 12 b, . . . ) is an application program that runs on the normal OS 11.
In the following explanations, the debugger 14 attaches to the normal program 12 that runs in the normal mode, and performs the debugging on the attached normal program (e.g. the normal program 12 a) and the protected program (e.g. the protected program 8 a) that cooperates with the normal program.
The access control list 53 includes two types of information. One of the types is area information for controlling accesses, and the other is access permission information relating to the area information. The following explains an access control list 53 a for controlling accesses based on memory addresses and an access control list 53 b for controlling accesses based on symbols. Note that symbols are, specifically, variables, functions, and the likes included in programs.
FIG. 6A shows the data structure of the access control list 53 a for specifying the areas, where accesses are controlled, by memory addresses. Each area where accesses are controlled is specified by a start address and an end address.
As FIG. 6A shows, each record of the access control list 53 a includes a start address 61 a, an end address 62 a and access permission information 63 a.
The start address 61 a and the end address 62 a respectively indicate the start address and the end address of a memory area where accesses are controlled.
The access permission information 63 a shows whether to permit accesses to the memory area indicated by the start address 61 a and the end address 62 a. When permitting accesses, the access permission information 63 a shows “access allowed”, and when not permitting accesses, the access permission information 63 a shows “access denied”, using one-bit information, for example. The access control list 53 a includes a plurality of records.
Note that the top of the list, an area which is not specified by the start address 61 a and the end address 62 a is defined as “default”. Accesses to the “default” area in this embodiment are prohibited as “access denied”.
Also note that the addresses indicated by the start address 61 a and soon in this embodiment are relative addresses. Specifically, the decryption-use header information 54 of the protected program 8 shows a memory address used for loading the protected program 8 into the memory, and relative addresses with reference to this address, which is assumed as “0”, are indicated by the start address 61 a and so on. As a matter of course, the addresses indicated by the start address 61 a may be absolute addresses of the memory.
The access judging unit 23 acquires the access control list 53 a and the debug information of the protected program 8 a. Also, using the debug information of the protected program 8 a, the access judging unit 23 converts a symbol, accesses to which is requested by the debugger 14, to an address.
The access judging unit 2, judges whether each memory area indicated by the start address 61 a and the end address 62 a of the access control list 53 a includes the address as the conversion result, in the top-to-bottom order of the access control list 53 a. If judging affirmatively, the access judging unit 23 acquires the access permission information 63 a associated with the corresponding area, and notifies the control unit 21 of the information indicated by the access permission information 63 a, namely either the “access allowed” or the “access denied”. If any memory area does not include the address, the access judging unit 23 notifies the control unit 21 of the either the “access allowed” or the “access denied”, based on the access permission information 63 a associated with the “default” at the top of the list.
FIG. 6B is the data structure of the access control list 53 b for indicating areas to be access-controlled by symbol names.
As FIG. 6B shows, each record of the access control list 53 b includes a symbol name 64 b and access permission information 65 b.
The symbol name 64 b shows the name of a symbol as the target of the access control.
The access permission information 65 b shows whether to permit accesses to the symbol indicated by the symbol name 64 b.
As FIG. 6B shows, the access control list 53 b shows, for each symbol, whether to permit accesses to the symbol. In FIG. 6B, “access allowed” means that the access is permitted, and “access denied” means that the access is prohibited.
Note that symbols that are not indicated by the symbol name 64 b are defined as “default”. In this embodiment, accesses to the “default” symbols are prohibited as “access denied”.
The access judging unit 23 acquires the access control list 53 b. The access judging unit 23 judges whether the name of the symbol, accesses to which is requested by the debugger 14, is the same as the symbol name indicated by the symbol name 64 b in the top-to-bottom order of the access control list 53 b. If they are the same, the access judging unit 23 acquires the access permission information 65 b that is associated with the symbol name, and notifies the control unit 21 of the information indicated by the access permission information 65 b, namely either “access allowed” or “access denied”. If they are not the same, the access judging unit 23 notifies the control unit 21 of either the “access allowed” or “access denied” based on the access permission information 65 b associated with the “default” at the top of the list.
In the first embodiment, it is assumed that the access control lists 53 a and 53 b respectively contain the access permission information 63 a and the access permission information 65 b in association with the “default” symbol at the top of the list. However, the present invention is not limited to this.
In the case where a memory area or a symbol name is not included in the access control list 53 a and 53 b, it may be always regarded as “access allowed”, or alternatively, it may be always regarded as “access denied”.
In the example above, the symbol specified by the debugger 14 is once converted to an address for judging the access permission according to the access control list 53 a. However, if the debugger 14 uses the memory addresses, the access permission can be directly judged according to the addresses specified by the debugger 14.
Firstly, the following describes loading of the protected program 8. In the following explanation, it is assumed that the normal program 12 and the protected program 8 cooperate with each other. The normal program 12 calls the protected program 8, via the switching driver 13 as the device driver of the normal OS 11 and the protected OS 6. In the following explanation, it is assumed that the normal program 12 a cooperate with the protected program 8 a. The same applies to the case where the normal program 12 b operates or where the protected program 8 b cooperates.
As FIG. 8 shows, firstly the normal program 12 a is started up. Upon started up, the normal program 12 a opens the switching driver 13 as preprocessing for switching the operation mode to the protection mode (Step S201). Here, to open means to enable the switching driver 14 to communicate with processes that run in the protection mode, such as the protected OS 6.
To run the protected program 3 a, the normal program 12 a specifies an encrypted protected-program, and sends a request to the protected OS 6 via the switching driver 14 to load the encrypted protected-program into the memory (Step S202). Here, it is assumed that the protected program 8 a is generated by decrypting the encrypted protected-program.
The protected OS 6 decrypted the encrypted protected-program based on the acquired information required for the loading. The protected OS 6 loads the protected program 8 a acquired by the decryption into the memory area that is managed in the protection mode (Step S204) to enable execution of the protected program 8 a.
When the protected program 8 a comes into an executable state, the processing returns from the protected OS 6 to the normal program 12 a via the switching driver 13 (Step S205). In other words, the protected OS 6 hands the execution right of the processes to the normal program 12 a, and the normal program 12 a runs again.
The following describes a case where the normal program 12, running in the normal OS 11, requires execution of the functions of the protected program 8 a.
The normal program 12 a sends a request to execute the protected program 8 a to the protected OS 6 via the normal program 12 a (Step S206). The request shows instructions and processing that are to be executed by the protected program 8 a.
The OS 6 receives the request to execute the protected program 8 a, executes the protected program 8 a, and performs processing according to the execution request (Step S207).
Upon completing the execution of the protected program 8 a, processing returns from the protected program 8 a to the normal program 12 a, via the protected OS 6 and the switching driver 13 (Step S208).
If the normal program 12 a uses the processing result of the protected program 8, the protected program 8 a and the normal program 12 a hands the processing results to each other via the switching mechanism 3 and the switching driver 13.
Every time execution of the functions of the protected program 8 a is required, the Steps S206 to S208 described above are performed.
The following describes the operations of the normal program 12 a completing the use of the protected program 8 a.
FIG. 10 is a flowchart showing operations of the normal program 12 a completing the use of the protected program 8 a.
As FIG. 10 shows, upon completion of the use of the protected program 8 a, the normal program 12 a output a request for deleting the protected program 8 a to the protected OS 6 via the switching driver 13 (Step S209). Note that the request for deletion indicates a protected program 8 to be deleted. In this embodiment, the protected program 8 a is deleted from the memory according to the request.
Upon receiving the request for deletion, the protected OS 8 deletes the protected program 8 a from the memory (Step S210). After that, the processing returns from the protected OS 6 to the normal program 12 a via the switching driver 13. As a result of this operation, the functions of the protected program 8 a are disabled until when the protected program 8 a is loaded again. Also, the protected program 8 a in plain text is deleted from the memory. This protects the data processing apparatus against unauthorized tampering.
After that, when it becomes unnecessary for the normal program 12 a to operate in the protection mode, the switching driver 13 is closed (S211). Here, to close means to disable the switching driver 13 to perform communications with the protected OS 6 and so on.
Next, the following describes operations performed by the debugger 14 to debug the normal program 1 w and the protected program 8. Firstly, the preprocessing for the debugging is explained.
In the following operations, the normal program 12 a and the protected program 8 a cooperate with each other, and the debugger 14 debugs the normal program 12 a and the protected program 8 a.
According to an instruction for attachment received from the program developer, the debugger 14 is attached to the normal program 12 a for debugging the normal program 12 a (S301).
The debugger 14 notifies the debug function 7, operating in the protection mode, of the process ID of the normal program 12 a via the debugger-use switching driver 15 (Step S303).
The debug function 7 stores the notified process ID, and when starting execution of the protected program 8 a, activates the stop flag which shows whether to stop the protected program immediately after the execution start of the protected program 8 a (Step S304). The reason for activating the stop flag is described later in “1.4.3.2 Supplementary explanations of preprocessing”. The sop flag is one-bit information, and stored in the storage area within the protection mechanism, such as the register and the memory.
The debugger 14 debugs the normal program 12 a upon receiving an instruction pertaining to debugging from the program developer. Upon completion of required processing, the debugger 14 receives an instruction to restart the execution of the program, and accordingly restarts the execution of the normal program 12 a as the debugging target (S305).
The restarted normal program 12 a opens the switching driver 13, and requests the protected OS 6 to load the protected program 8 a (S306) and execute the protected program 8 a (S307), via the switching driver 13.
Note that the loading performed in Step S306 is almost the same as that performed in Steps S232, S203 and S204 in FIG. 7. Also, the execution performed in Step S307 is almost the same as that performed in Steps S206, S207 and S208 in FIG. 8. The difference is that the process ID of the normal program 12 a is notified to the debug function 7 together with data handed between the processes (S303) because when the debugger 7 is operating, the debugger function 7 judges whether the normal program 12 a is being debugged.
Also, upon receiving a request for executing the protected program 8 a, the protected OS 6 request the debug function 7 to perform the preprocessing (S308). The debug function 7 receives the request, and performs the preprocessing. Here, the preprocessing means that the debug function 7 judges whether the stop flag corresponding to the process ID is active or not (S309), and if active (S309: YES), changes an instruction located at the entry point of the protected program 8 a to a break instruction (S310). If the stop flag is not active (S309: NO), the debug function 7 does not change the instruction at the entry point.
The protected OS6 executes the protected program 8 a (S311).
The following explains the reason for such operations: In the first embodiment, as described in the explanations of the operations in the case of not performing the debugging, the protected program 8 a is loaded when called by the normal program 12 a, and deleted when it becomes unnecessary. Here, since the program of the first embodiment usually begins with the execution of the normal program 12 a, it is difficult for the program developer to recognize that the processing is switched to the execution of the protected program 8 a.
Also, since the debugger 14 of the first embodiment is usually attached to the normal program, the program developer cannot directly set a break point to the protected program 8 a, and it is difficult to debug the protected program 8 a.
Accordingly, the processing is stopped when the protected program 8 a is read, so that the program developer is notified of that the processing is moved to the protected program 8 a and given an opportunity to set the break point to the protected program 8 a.
FIG. 12 is a flowchart showing debugging of the protected program 8 a using the debugger 14 when a debug exception has caused due to a break point during the execution of the protected program 8 a.
As FIG. 12 shows, if a debug exception is caused due to a break point that has been set to the protected program 8 during the execution of the protected program 8 a, the protected OS 8 is notified of the debug exception (S401).
The debug function 7 judges whether the debugging of the protected program 8 a and accesses to a prescribed part of the protected program 8 a pertaining to the debugging are permitted, by the debugger ID judging unit 22 and the access judging unit 23 (S406).
In Step S406, if it is judged that the debugging and the accesses are permitted (S406: YES), the debug information acquiring unit 25 acquires the debug information of the protected program 8 a, and copy the debug information to the communication area for the debugging use (S407). After the copying, the debug function 7 notifies the debugger 14 of the completion of the acquisition of the debugging information, via the protected OS 6 and the debugger-use switching driver 15, and then the processing returns from the debug function 7 to the debugger 14 (S408).
After that, upon completion of necessary operations by the program developer referring to the debug information, the debugger 14 receives a prescribed instruction from the program developer, and request the protected OS 6 via the switching driver 14 to restart the execution of the protected program 8 a as the debug target (S410).
Receiving the request, the protected OS 6 restarts the execution of the protected program 8 a (S411).
The explanation above explains a case where a debug exception due to a break point occurs during the execution of the protected program 8 a. In addition, there are various patterns of debugging with use of the debug function 7. Specifically, the program developer requests other types of debugging, such as setting of break points and setting and acquisition of register values and memory values, and the debug function performs debugging according to the request. In such cases, the debug function 7 (To be exact, each function unit of the secure debugger 24) performs processing by following the same flow. Accordingly, explanations of these cases are omitted here.
According to the first embodiment, it is assumed that when a debug exception occurs, debugging of the protected program 8 a pertaining to the debug exception can be performed. However, this is not limited to the protected program 8. The debugging may be performed on a normal program such as the normal program 12 a, being debugged by the debugger 14.
3.1 Explanation of Structure 3.1.1 Debugger ID Management Server 81
4.1 Explanation of GUI 150 a
FIG. 18A shows a GUI 150 a which shows a screen of the display unit in the case where the debugger 14 is attaching to the normal program 12 and debugging the normal program 12. FIG. 18B shows a screen of the display unit in the case where the debugger 14 is executing the protected program 8 and debugging the normal program 12 and the protected program 8.
As FIG. 18A shows, the GUI 150 a includes a code display part 151, a register display part 152, a memory display part 153, a symbol display part 154, a watch point display part 155, a call stack display part 156, a window title display part 157, and a menu display part 158.
4.2 Supplementary explanations of GUI 150 a
4.3 Explanations of GUI 150 b
As FIG. 18B shows, the GUI 150 b includes a debug window 160 for the normal program and a debug window 161 for the protected program.
Upon being started up, the debugger 14 displays a prompt that is different from the console, such as “(dbg)”, to show that the debugger 14 is available. This shows that it is possible to debug the normal program 12 (A display example 171 a of the debug result).
Moreover, if the protected program 8 is stopped during the execution, the debugger 14 changes the style of the prompts, messages from the debugger 14 and the characters input by the user to be italic, to show that the protected program 8 is stopped during the execution, so that the user can recognize the fact (A display example 171 b of the debug result).
At this moment, the prompt changes from “(dbg)” to “(dbg-sec)”. However, the style of the characters does not change to italic or the like, because the state is the same, i.e., the normal program 12 still stops in the middle of the execution (A display example 171 c of the debug result).
At this moment, the prompt changes from “(dbg-sec)” to “(dbg)”. However, the style of the characters does not change to the normal style, because the state is the same, i.e., the protected program 8 still stops in the middle of the execution (A display example 171 d of the debug result).
(1) In the embodiments above, it is assumed that the permitted-debugger ID information 52 and the access control list 53 are included in the protected program 8. However, the permitted-debugger ID information 52 and the access control list 53 may be acquired from outside the data processing apparatus. If this is the case, information that shows correspondence between the protected program 8 a and the permitted-debugger ID information 52, etc. may be acquired as well.
(10) In the embodiments above, the explanation is based on the assumption that a debug exception due to a break point is detected during the execution of the protected program 8 a and the protected program 8 a is debugged. However, the present invention is not limited to this example. The debugging by the debugger 14 may be performed according to detection of a general error interruption occurred during the execution of the protected program 8. A general error interruption is caused by, for example, occurrence of division by 0 during the execution of the protected program 8, and occurrence of an overflow. The debugger 14 can debug the protected program 8 by, for example, the protected OS 6 notifying the switching driver 13 of the debug exception (e.g. S402) when a general error interruption occurs.
US12/298,198 2006-04-24 2007-04-24 Data processing device, method, program, integrated circuit, and program generating device Abandoned US20090307783A1 (en)
JP2006-118881 2006-04-24
JP2006118881 2006-04-24
PCT/JP2007/058838 WO2007125911A1 (en) 2006-04-24 2007-04-24 Data processing device, method, program, integrated circuit, and program generating device
US20090307783A1 true US20090307783A1 (en) 2009-12-10
ID=38655437
US12/298,198 Abandoned US20090307783A1 (en) 2006-04-24 2007-04-24 Data processing device, method, program, integrated circuit, and program generating device
US (1) US20090307783A1 (en)
EP (1) EP2023248B1 (en)
JP (1) JP4814319B2 (en)
CN (1) CN101427222B (en)
WO (1) WO2007125911A1 (en)
US20120204255A1 (en) * 2011-02-08 2012-08-09 Pantech Co., Ltd. Mobile platform security apparatus and method
US20140115719A1 (en) * 2012-10-24 2014-04-24 Fujitsu Limited Information processing apparatus and control method
JP2014191509A (en) * 2013-03-26 2014-10-06 Toshiba Corp Information processing device, information processing program
US9749304B1 (en) * 2013-07-30 2017-08-29 Google Inc. System and methods for accessing multiple resources via one identifier
US9817641B1 (en) * 2009-02-04 2017-11-14 Sprint Communications Company L.P. Facilitating application development using protected components
JP2012128463A (en) * 2009-04-10 2012-07-05 Panasonic Corp Debug permission device
CN101794252B (en) 2009-12-23 2013-03-13 张曙光 Method for realizing operator single-step debugging at source program level
CN103684899B (en) * 2012-09-17 2019-01-08 腾讯科技（深圳）有限公司 remote debugging method and device
JP2007226276A (en) 2004-03-24 2007-09-06 Matsushita Electric Ind Co Ltd Debug permission device system
JP2006065555A (en) * 2004-08-26 2006-03-09 Matsushita Electric Ind Co Ltd Apparatus and method for developing program
2007-04-24 US US12/298,198 patent/US20090307783A1/en not_active Abandoned
2007-04-24 JP JP2008513216A patent/JP4814319B2/en active Active
2007-04-24 EP EP07742273.1A patent/EP2023248B1/en active Active
2007-04-24 CN CN 200780014735 patent/CN101427222B/en active IP Right Grant
2007-04-24 WO PCT/JP2007/058838 patent/WO2007125911A1/en active Application Filing
US9015826B2 (en) * 2011-02-08 2015-04-21 Pantech Co., Ltd. Mobile platform security apparatus and method
WO2007125911A1 (en) 2007-11-08
JP4814319B2 (en) 2011-11-16
CN101427222A (en) 2009-05-06
JPWO2007125911A1 (en) 2009-09-10
EP2023248B1 (en) 2018-10-24
EP2023248A1 (en) 2009-02-11
CN101427222B (en) 2012-11-21
EP2023248A4 (en) 2013-01-16
US20070226492A1 (en) 2007-09-27 Secure processor architecture for use with a digital rights management (drm) system on a computing device
US8407488B2 (en) 2013-03-26 Semiconductor device including encryption section, semiconductor device including external interface, and content reproduction method
JP3880933B2 (en) 2007-02-14 Data access control method according to the tamper resistant microprocessor and a cache memory mounted processor
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAEDA, MANABU;MATSUSHIMA, HIDEKI;ITO, YOSHIKATSU;REEL/FRAME:021793/0150