WO2008032332A1 - Protection scheme for embedded software - Google Patents

Protection scheme for embedded software Download PDF

Info

Publication number
WO2008032332A1
WO2008032332A1 PCT/IN2006/000350 IN2006000350W WO2008032332A1 WO 2008032332 A1 WO2008032332 A1 WO 2008032332A1 IN 2006000350 W IN2006000350 W IN 2006000350W WO 2008032332 A1 WO2008032332 A1 WO 2008032332A1
Authority
WO
WIPO (PCT)
Prior art keywords
target device
embedded software
license key
key manager
lkey
Prior art date
Application number
PCT/IN2006/000350
Other languages
French (fr)
Inventor
Shyam Prasad Kompadav Shetty
Jayasimha Narasimha Murthy Holakal
Sreeepathi Karkala Tantri
Original Assignee
Shyam Prasad Kompadav Shetty
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shyam Prasad Kompadav Shetty filed Critical Shyam Prasad Kompadav Shetty
Priority to PCT/IN2006/000350 priority Critical patent/WO2008032332A1/en
Publication of WO2008032332A1 publication Critical patent/WO2008032332A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user

Definitions

  • the present invention relates to IP protection scheme for embedded software and more particularly to IP protection scheme for embedded software which has an authorization mechanism to authorize the devices to execute the valid code already present in the device.
  • a target device containing the embedded software, wherein the said device needs to be authorized as authentic to use the said software.
  • LKM License Key Manager
  • the method comprises of powering the target device.
  • the method further comprises of initializing the target device to be visible for the LKM.
  • the method further comprises of the LKM opening a secure channel for communication.
  • the method involves the target device generating the digital signature of target side executable image.
  • the method further comprising of the target device encrypting the said digital signature of target side executable image using the digital signature of the RAM of the target device and transferring the said encrypted digital signature to the LKM.
  • the invention there is provided a method to protect the embedded software wherein the method involves the LKM decrypting the said encrypted digital signature of target side executable image using the digital signature of the RAM of the said target device.
  • the invention there is provided a method to protect the embedded software wherein the method involves the comparison of the said decrypted digital signature of target side executable image with the computed value for the digital signature of the image by the LKM.
  • the LKM further sends an acknowledgment if the said comparison matches.
  • the method further involves the said LKM encrypting the Lkey using the said digital signature of RAM.
  • the method further involves the LKM updating the secure embedded database.
  • the method further involves the said encrypted Lkey being sent to the said target device by the said LKM.
  • the method involves the said Lkey and the device identifier is saved by the target device.
  • the method further involves the encrypted Lkey being decrypted by the target device and transferring the transformed Lkey to the said LKM.
  • the method involves the target device sending the success message to the said LKM.
  • the method further involves the target device blowing the fuse and performs reset.
  • FIG.l shows the overview of the target side power-up behavior.
  • FIG.2 shows the target side authorization process.
  • FIG.3 shows the License Key Manager side authorization process.
  • FIG.4 shows the block diagram of the overview of the IP protection scheme.
  • FIG.5 shows the powering up behavior of the Bluetooth device.
  • FIG.6 shows a overview of the authorization process of the Bluetooth devices.
  • FIG.7 shows an authorization process for Bluetooth device.
  • FIG.8 shows an authorization process for the License Key Manager side.
  • FIG.9 shows a basic authorization using Internet as medium for communication.
  • FIG.l illustrates the overview of the target side power-up behavior wherein the target device containing the embedded software is validated to use the said software by the License Key Manager (LKM) wherein the LKM is a secure, tamper-proof device running secure algorithms and it maintains information in a non-volatile memory including but not limited to the license information which includes but is not limited to the number of target devices authorized, the maximum number of the valid licenses, name of the customer, the name of the application, the version information of the embedded software , the digital signature of the executable image and the information about the latest generated Lkey.
  • the said LKM can include but not limited to a computing device.
  • the said non-volatile memory is unreadable from outside the target device. An example of the above mentioned specific information maintained in the database is given below.
  • the Power Up 101 of the target device shows the initial powering of the device; 102 depicts all the basic initialization process in the target device.
  • the target device checks if it has received the License Key (Lkey) from the License Key Manager (LKM) as shown by 103. If the Lkey is not received, the Authorization Process 104 is initiated as shown in the figure. After the completion of the authorization process 104, the basic initialization of the target device 102 is performed as shown in the figure.
  • the aforementioned target checks the validity of the target device as shown by 105. If the target device is not valid, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 106.
  • the Lkey is further validated wherein regular run-time checks are performed at random points in the application and stack codes. If the said Lkey is not validated, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 108.
  • the device containing the embedded software continues to operate normally as shown by 109 in FIG.l. [30] Every embedded software distribution is accompanied by the License Key Manager thus controlling the number of devices manufactured with the said embedded software.
  • FIG. 2 illustrates the target side authorization process
  • FIG. 3 illustrates the authorization process performed by the LKM.
  • Target side authorization process 201 in FIG.2 depicts the process performed by the target device to get validation from the said LKM to use the embedded software contained in it.
  • the target device is initialized to be visible for LKM 202.
  • LKM side Authorization process 301 in FIG.3 depicts the authorization performed by the LKM to validate the target device as authentic.
  • the LKM searches for the target device as shown by 302 in the FIG.3.
  • the LKM opens secure channel 303; in the event of the LKM not being successful in opening the secure channel as described hereinabove, the authorization process returns to searching for target devices as shown by 302 of FIG.3.
  • the target device checks for the said secure channel as shown by 203 in FIG. 2. In the event of the said target device not being successful in detecting the said secure channel, the above mentioned process to wait for the secure channel to be opened by LKM 203 is repeated as shown by the loop in FIG. 2.
  • the method described herein involves the Digital Signatures of the target side executable image and target side RAM, which are henceforth depicted as DSIG_img and DSIG_RAM respectively.
  • the said target device After the LKM opens a secure communication channel to the target device, the said target device generates a Digital Signature of the RAM (DSIGJRAM) as shown by 204 in FIG.2.
  • the LKM after being successful in opening the secure channel, checks if the DSIG_RAM packet is received from the target as shown by 304 in FIG.3. If the DSIG_RAM packet is not received from the target, the LKM checks if the stipulated time for it to wait for the said DSIG-RAM has exceeded as shown in Timeout 305.
  • Timeout 305 is affirmative, which is, the stipulated time for the LKM to wait for the DSIG-RAM has exceeded, said LKM sends a Negative Acknowledgment (NACK) to the target and closes the session as shown 309.
  • NACK Negative Acknowledgment
  • the LKM searches for other devices 302 as shown in FIG.2. If the said stipulated time has not been exceeded, the LKM searches for the DSIG_RAM from the target again as indicated by the loop in FIG.3.
  • the target device further generates the Digital Signature of the target side executable image (DSIG_img) which is encrypted with the aforementioned DSIG_RAM and sends it to the LKM as shown by 205 in FIG.2.
  • the LKM waits for the DSIG_img after receiving the DSIG_RAM from the target device as shown by 306 in FIG. 3. If the DSIG_img packet is not received from the target, the LKM checks if the stipulated time is exceeded as shown in Timeout 307. If the Timeout 307 is affirmative, which is, the stipulated time for the LKM to wait for the DSIG_img has been exceeded, then the LKM sends a NACK to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices 302 as shown in the FIG. 3. If the stipulated time has not been exceeded, then LKM waits for the DSIG_img packet from the target again as indicated by the loop in FIG.3.
  • the LKM decrypts the DSIGJmg using the DSIG_RAM received from the target as shown above, and compares it with the computed DSIG 308 in FIG.3. In the event wherein the comparison of the decrypted DSIG_img and Computed DSIG does not match, the LKM sends a Negative Acknowledgment (NACK) to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices
  • the LKM sends Acknowledgment (ACK) to the target device.
  • ACK and NACK are encrypted executable code wherein if the target device is unable to decrypt it, the embedded software would execute an illegal instruction, which triggers execution of code to self destructs itself.
  • the ACK/NACK is thus used to authenticate the target device.
  • the target device checks if the above mentioned ACK or NACK is received 206, if the said ACK/NACK is not received, the target device perform the above mentioned check again; if the ACK/NACK is received, the target device decrypts and executes the ACK/NACK code as shown by 207 in FIG.2. In the event of the ACK/NACK code being decrypted wrongly, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 208 in FIG.2.
  • the target device decrypts the ACK correctly it can proceed to the next step of waiting for the encrypted Lkey from LKM 209.
  • the LKM generates the Lkey, updates the database, encrypts the said Lkey using the aforementioned DSIG-RAM; the said encrypted Lkey is sent to target device as shown by 310.
  • the target device checks if it has received the encrypted Lkey packet from the LKM iteratively until the said packet is received as shown 209.
  • the target device saves the Lkey and the device identifier, decrypts the above mentioned Lkey packet using DSIG_img and sends the decrypted (transformed)
  • the LKM checks if it has received the Lkey 311, which is decrypted using
  • the LKM checks if the stipulated time is exceeded as shown in Timeout 312. If the Timeout 312 is affirmative, which is the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, the LKM sends NACK and closes the session 309 and the authorization process returns to searching for target devices as in 302 of FIG.3. If the stipulated time has not been exceeded, then LKM waits for the said decrypted Lkey from the target again as indicated by the loop in FIG.3.
  • the LKM receives the said decrypted (transformed) Lkey it compares it with the locally computed Lkey as shown by 313. In the event wherein the comparison of the decrypted Lkey and computed Lkey does not match, the LKM sends a NACK to the target and closes the session as shown by 309 in FIG.3. The LKM then scans for other devices 302 as shown in the FIG.3. If the decrypted (transformed) Lkey and computed Lkey match, the LKM sends an ACK to the target device as shown in FIG. 3.
  • the target device checks if the above mentioned ACK or NACK is received by it as shown by 211. If the said ACK/NACK is not received the target device waits till the
  • the target device blows the fuse and sends SUCCESS message to the LKM and performs RESET as shown by 214.
  • the LKM checks if it has received the SUCCESS message as mentioned above by the target device. If the said SUCCESS message is not received from the target, the LKM checks if the stipulated time is exceeded as shown in Timeout 316. If the Timeout 316 is affirmative, which is, if the stipulated time for the LKM to wait for the said SUCCESS has exceeded, then LKM sends a NACK to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices 302 as shown in the FIG. 3. If the stipulated time has not been exceeded, then LKM waits for the SUCCESS message from the target again as indicated by the loop in FIG.3. [47] If the LKM gets the SUCCESS sent by the target device, the session is closed as shown by 316 in FIG.3 and the LKM continues to scan for other devices for authorization 302 as shown in FIG.3.
  • the block diagram in FIG.4 illustrates the handshake between the LKM and the target device over secure communication channels.
  • the License key manager 401 is an authorization device which authorizes the target device 402 to execute the software code contained in it.
  • FIG.5 illustrates the overview of the authorization mechanism wherein the Bluetooth devices 602 and 603 containing the embedded software is authorized to use the valid software using the Bluetooth License Key manager (LKM) 604, wherein the LKM 604 is a secure tamper-proof device running secure algorithms and it maintains information in a non-volatile memory including but not limited to the license information which includes but is not limited to the number of devices authorized, the number of the valid licenses still remaining, valid customer and application information.
  • the said LKM 604 can include but not limited to a computing device.
  • the said non-volatile memory is unreadable from outside the said Bluetooth devices 602 and 603. The aforementioned information is maintained in a tamper-proof, nonvolatile, secure embedded database.
  • the Bluetooth devices 602 and 603 are programmed by 601 in FIG.6.
  • 501 of the Bluetooth devices 602 and 603 shows the initial powering up of the Bluetooth devices 602 and 603; 502 depicts the basic initialization process in the
  • Bluetooth devices 602 and 603. The Bluetooth devices 602 and 603 check if the
  • License key has been received from the LKM 604 as shown by 503. [52] If the Lkey is not received, the authorization process 504 is initiated as shown by FIG.5. After the completion of the authorization process 504, the basic initialization of the target device 502 is performed as shown in the figure. The aforementioned LKM 604 checks the validity of the Bluetooth devices 602 and 603 as shown by step
  • the Bluetooth devices 602 and 603 are not valid, the embedded software on the said Bluetooth devices 602 and 603 executes an illegal instruction which triggers execution of code to self destruct itself as shown by 506. If the said Bluetooth devices 602 and 603 certify themselves as valid as shown in the figure, the Lkey is further validated wherein regular run-time checks are performed at random points in the application and stack codes. If the said Lkey is not validated, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by508. If the said Lkey is validated, the Bluetooth devices 602 and 603 containing the embedded software continue to operate normally as shown by 509 in FIG. 5.
  • the flowchart in FIG.7 shows the Bluetooth side authorization process.
  • the flowchart in FIG.8 shows the authorization process performed by the LKM 604.
  • the Bluetooth side authorization process shown by step 701 in FIG.7 depicts the process performed by the Bluetooth devices 602 and 603 to get validation of Bluetooth devices 602 and 603 to get validation from the said LBGVI 604 to use the embedded software contained in it.
  • the Bluetooth devices 602 and 603 are initialized to be visible for LKM 604.
  • LKM side authorization process shown by step 801 in FIG.8 depicts the authorization performed by the LKM 604 to validate the Bluetooth devices 602 and 603 as authentic.
  • the LKM 604 searches for the Bluetooth devices 602 and 603 where the Bluetooth chip is programmed with user defined "Security Class of Devices" (Security CoD) as shown by step 802 in the figure 8.
  • the LKM side searches for the next device ID of the Bluetooth devices as shown by step 803. After the end of the list the Bluetooth devices 602 and 603 where the Bluetooth chip is programmed with user defined "Security Class of Devices" (Security CoD) as shown by step 802 in the figure 8.
  • Security CoD Security Class of Devices
  • the LKM 604 opens secure SPP channel with the Bluetooth devices 602 and 603 as shown by step 805.
  • the authorization process returns to searching for target devices as in 802 of FIG.8.
  • the target device checks for the said secure SPP channel as shown as 703 in FIG. 7. In the event of the said Bluetooth devices 602 and 603 not being successful in detecting the said secure SPP channel, the above mentioned process to wait for the secure SPP channel to be opened by LKM 604 is repeated as shown by the loop for 703 in
  • the method described herein involves the Digital Signatures of the Bluetooth side executable image and RAM which are depicted as DSIG_img and DSIG_RAM henceforth. [62] If the secure channel opened by the said LKM is detected by the Bluetooth devices
  • the said Bluetooth devices 602 and 603 generate a Digital Signature of the RAM (DSIG_RAM) and send it to LKM 604 as shown by 704 in FIG.7.
  • DSIG_RAM Digital Signature of the RAM
  • the LKM after being successful in opening the secure channel, checks if the DSIG-RAM packet is received from the Bluetooth devices 602 and 603 as shown by 806 in FIG.8.
  • the LKM 604 checks if the time stipulated for it to wait for the said DSIG_RAM has exceeded as shown in Timeout 807. If the Timeout 807 is affirmative, where the stipulated time for the LKM to wait for the DSIG_RAM has exceeded, then LKM sends a Negative acknowledgment (NACK) to the Bluetooth devices 602 and 603 and closes the session as shown by 811 in FIG.8. The LKM then searches for other devices as shown by 803 in FIG. 8. If the stipulated time has not been exceeded, the LKM waits for the DSIG_RAM from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
  • NACK Negative acknowledgment
  • the Bluetooth devices 602 and 603 further generates the Digital Signature of the
  • Bluetooth device side executable image (DSIG_img) which is encrypted with the aforementioned DSIG-RAM and sent to LKM 604 as shown by 705 in FIG.7.
  • the LKM waits for the DSIGJmg after receiving the DSIG_RAM from the Bluetooth devices 602 and 603 as shown by 808 in Fig. 8.
  • LKM checks if the stipulated time is exceeded as shown in Timeout 809. If the
  • Timeout 809 is affirmative, which is the stipulated time for the LKM to wait for the DSIG_img has exceeded, the LKM sends a NACK to the Bluetooth devices 602 and
  • the LKM then scans for other devices 803 as shown in the FIG. 8. If the stipulated time has not been exceeded, the LKM waits for the DSIG_img packet from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8,
  • the LKM decrypts the DSIG_img using the DSIG_RAM received from the Bluetooth devices 602 and 603 as shown above, and compares it with the locally computed DSIG as shown by 810 in FIG.8. In the event wherein the comparison of the decrypted DSIG_img and Computed DSIG does not match, the LKM sends a
  • Negative acknowledgment (NACK) to the Bluetooth devices 602 and 603 and closes the session as shown by 811 in FIG. 8.
  • the LKM then scans for other devices 803 as shown in the FIG. 8. If the encrypted DSIG_img and locally computed DSIG match, then LKM sends acknowledgment (ACK) to the Bluetooth devices 602 and 603 device.
  • ACK and NACK are encrypted executable code wherein if the target device is unable to decrypt it, the embedded software would execute an illegal instruction which triggers execution of code to self destruct itself.
  • the ACK/NACK is thus used to authenticate the target device.
  • the Bluetooth devices 602 and 603 check if the above mentioned ACK or NACK is received by it 806, if the said ACK/NACK is not received, the Bluetooth devices
  • FIG.2 if the ACK/NACK received, the Bluetooth devices 602 and 603 decrypt and execute the ACK/NACK code as shown by 807.
  • the LKM If the Bluetooth devices 602 and 603 decrypt the ACK correctly, the LKM generates the Lkey, updates the database and encrypts the said Lkey using the aforementioned
  • the said encrypted Lkey is sent to Bluetooth devices 602 and 603 devices as shown by 812 in FIG.8.
  • the Bluetooth devices 602 and 603 checks if it has received the encrypted Lkey packet from the LKM iteratively until the said packet is received as shown by 709 in FIG.7.
  • the Bluetooth devices 602 and 603 saves the said Lkey and BTID 3 decrypts the above mentioned Lkey packet using DSIG ⁇ img and sends the decrypted Lkey packet to the LKM as shown by 710 in FIG.7.
  • the LKM checks if it has received the Lkey which is decrypted using DSIG_img
  • the LKM checks if the stipulated time is exceeded as shown in Timeout 814. If the Timeout 814 is affirmative, which is the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, the LKM sends a NACK closes the session as shown by 811 in
  • FIG. S. The authorization process returns to searching for Bluetooth devices as shown by 803 of FIG.8. If the stipulated time has not been exceeded, then LKM waits for the said decrypted Lkey from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
  • the LKM receives the said decrypted Lkey, it compares it with the locally computed Lkey as shown by 815. In the event wherein the comparison of the decrypted Lkey and locally computed Lkey does not match, the LKM sends a NACK to the Bluetooth devices 602 and 603 and closes the session 811 in FIG. 8. The LKM then scans for other devices 803 as shown in the FIG. 8. If the encrypted
  • the LKM sends an ACK to the Bluetooth devices 602 and 603 as shown in FIG. 8.
  • the Bluetooth devices 602 and 603 checks if the above mentioned ACK or NACK is received by it as shown by 711, if the said ACK/NACK is not received, the
  • Bluetooth devices 602 and 603 perform the above mentioned check again; if the
  • the Bluetooth devices 602 and 603 decrypts and executes the ACK/NACK code as shown by 712 in FIG.7.
  • the embedded software in the Bluetooth devices 602 and 603 would execute an illegal instruction which triggers execution of code to self destruct itself as shown by 713 in FIG.7.
  • the Bluetooth devices 602 and 603 blows the fuse and sends SUCCESS message to the LKM and performs RESET as shown by 714.
  • the LKM checks if it has received the SUCCESS message as mentioned above from the Bluetooth devices 602 and 603 as shown by 816 in FIG.8. If the said SUCCESS message is not received from the Bluetooth devices 602 and 603, the LKM checks if the stipulated time is exceeded as shown in Timeout 817. If the Timeout 817 is affirmative, which is, if the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, then LKM sends a NACK to the Bluetooth devices
  • LKM then scans for other devices 803 as shown in the FIG. 8. If the stipulated time has not been exceeded, then LKM waits for SUCCESS message from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
  • the LKM gets the SUCCESS sent by the Bluetooth devices 602 and 603, the session is closed as shown by 818 in FIG.8 and the LKM continues to scan for other devices for authorization 803 as shown in FIG.8.
  • FIG.9 Another example with relation to the block diagram of FIG.9 shows IP protection technique which uses Internet for the secure communication channel.
  • the entity on which code is present 901 and 902 are authorized by the managing entity on the source side 904.
  • the authorization is done either through wired or wireless medium over the Internet 903.
  • the authorization of the target device by the LKM can be done using the secure communication channels including but not limiting to Bluetooth, Internet, WLAN, Ultra Wide Band (UWB), WiMAX, GSM, CDMA 5 USB, and IEEE1394. Further, the communication channels can include but not limited to wired and wireless communication channels which can be secure or insecure.
  • the secure communication channels including but not limiting to Bluetooth, Internet, WLAN, Ultra Wide Band (UWB), WiMAX, GSM, CDMA 5 USB, and IEEE1394.
  • the communication channels can include but not limited to wired and wireless communication channels which can be secure or insecure.

Abstract

The present invention is an Intellectual property protection scheme for the software embedded in a device. According to the invention, a License Key Manager (LKM) controls the authorization of the embedded software by verifying the data received from the target device on which the embedded software resides. Multiple levels of authorization involving certification of decrypted data sent by the device ascertain the complete validity of the target device to use the software embedded in it. The embedded software is tamper free and it is rendered unusable if the target is not authorized.

Description

PROTECTION SCHEME FOR EMBEDDED SOFTWARE
TECHNICAL FIELD OF THE INVENTION
[1] The present invention relates to IP protection scheme for embedded software and more particularly to IP protection scheme for embedded software which has an authorization mechanism to authorize the devices to execute the valid code already present in the device.
BACKGROUND AND PRIOR ART
[2] The unauthorized usage of software is rampant in the world leading to huge revenue losses to software companies. The companies protect the software by authorizing the devices trying to access it, but this mechanism does not serve the intended purpose if it can be tampered.
[3] Providing adequate protection to the embedded software ensures that the copying of the software is checked, but there exists a need to provide tamper free mechanisms where the software is made accessible only to authorized devices. Further, there exists a need to provide a protection mechanism in the event of the embedded software being tampered with to ensure the complete protection of the software which is intended for specific devices only.
SUMMARY OF THE INVENTION
[4] According to the invention there is provided a target device containing the embedded software, wherein the said device needs to be authorized as authentic to use the said software.
[5] According to the invention there is provided a License Key Manager (LKM) which authorizes the device containing the embedded software so as to enable the said device to use the said software. [6] According to the invention there is provided a secure communication channel between the device containing the embedded software and the LKM.
[7] According to the invention there is provided a method to protect the embedded software wherein the method comprises of powering the target device. The method further comprises of initializing the target device to be visible for the LKM.
[8] According to the invention there is provided a method to protect the embedded software wherein the method comprises of the LKM scanning for the target device.
The method further comprises of the LKM opening a secure channel for communication.
[9] According to the invention there is provided a method to protect the embedded software wherein the method involves the target device generating the digital signature of the RAM and transferring the said digital signature to the LKM.
[10] According to the invention there is provided a method to protect the embedded software wherein the method involves the target device generating the digital signature of target side executable image. The method further comprising of the target device encrypting the said digital signature of target side executable image using the digital signature of the RAM of the target device and transferring the said encrypted digital signature to the LKM.
[11] According to the invention there is provided a method to protect the embedded software wherein the method involves the LKM decrypting the said encrypted digital signature of target side executable image using the digital signature of the RAM of the said target device.
[12] According to the invention there is provided a method to protect the embedded software wherein the method involves the comparison of the said decrypted digital signature of target side executable image with the computed value for the digital signature of the image by the LKM. The LKM further sends an acknowledgment if the said comparison matches.
[13] According to the invention there is provided a method to protect the embedded software wherein the method involves the said LKM generating the License key
(Lkey). The method further involves the said LKM encrypting the Lkey using the said digital signature of RAM. The method further involves the LKM updating the secure embedded database. The method further involves the said encrypted Lkey being sent to the said target device by the said LKM.
[14] According to the invention there is provided a method to protect the embedded software wherein the method involves the said Lkey and the device identifier is saved by the target device. The method further involves the encrypted Lkey being decrypted by the target device and transferring the transformed Lkey to the said LKM.
[15] According to the invention there is provided a method to protect the embedded software wherein the method involves the LKM comparing the said Lkey with the computed Lkey.
[16] According to the invention there is provided a method to protect the embedded software wherein the method involves the target device sending the success message to the said LKM. The method further involves the target device blowing the fuse and performs reset.
[17] According to the invention there is provided a method to protect the embedded software wherein the method involves the LKM closing the session after receiving the said success message from the target device, indicating the authorization process has completed successfully.
BRIEF DESCRIPTION OF DIAGRAM [18] The diagram in FIG.l shows the overview of the target side power-up behavior.
[19] The diagram in FIG.2 shows the target side authorization process.
[20] The diagram in FIG.3 shows the License Key Manager side authorization process.
[21] The diagram in FIG.4 shows the block diagram of the overview of the IP protection scheme.
[22] The diagram in FIG.5 shows the powering up behavior of the Bluetooth device.
[23] The block diagram in FIG.6 shows a overview of the authorization process of the Bluetooth devices.
[24] The flowchart in FIG.7 shows an authorization process for Bluetooth device.
[25] The flowchart in FIG.8 shows an authorization process for the License Key Manager side.
[26] The block diagram in FIG.9 shows a basic authorization using Internet as medium for communication.
DETAILED DESCRIPTION
[27] FIG.l illustrates the overview of the target side power-up behavior wherein the target device containing the embedded software is validated to use the said software by the License Key Manager (LKM) wherein the LKM is a secure, tamper-proof device running secure algorithms and it maintains information in a non-volatile memory including but not limited to the license information which includes but is not limited to the number of target devices authorized, the maximum number of the valid licenses, name of the customer, the name of the application, the version information of the embedded software , the digital signature of the executable image and the information about the latest generated Lkey. The said LKM can include but not limited to a computing device. The said non-volatile memory is unreadable from outside the target device. An example of the above mentioned specific information maintained in the database is given below.
Customer Name XYZ Inc. Application Name Stereo Headset Version Information V3.2.1.4 Digital Signature of the executable image "% Maximum number of valid licenses 100000
Number of devices authorized 98754 Latest generated LKJEY asda*&Λ&Λ@SAKKK
[28] The aforementioned information is maintained in a tamper-proof, non-volatile, secure embedded database.
[29] The Power Up 101 of the target device shows the initial powering of the device; 102 depicts all the basic initialization process in the target device. The target device checks if it has received the License Key (Lkey) from the License Key Manager (LKM) as shown by 103. If the Lkey is not received, the Authorization Process 104 is initiated as shown in the figure. After the completion of the authorization process 104, the basic initialization of the target device 102 is performed as shown in the figure. The aforementioned target checks the validity of the target device as shown by 105. If the target device is not valid, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 106. If the said target device certifies itself as valid as shown in the figure, the Lkey is further validated wherein regular run-time checks are performed at random points in the application and stack codes. If the said Lkey is not validated, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 108.
If the said Lkey is validated, the device containing the embedded software continues to operate normally as shown by 109 in FIG.l. [30] Every embedded software distribution is accompanied by the License Key Manager thus controlling the number of devices manufactured with the said embedded software.
[31] The authorization mechanism wherein the target device containing the embedded software is validated to use the said software by the target as shown in FIG. 1 is explained in conjunction with the processes performed by the target device and the LKM as illustrated in FIG. 2 and FIG. 3 respectively. FIG. 2 illustrates the target side authorization process and FIG. 3 illustrates the authorization process performed by the LKM.
[32] Target side authorization process 201 in FIG.2 depicts the process performed by the target device to get validation from the said LKM to use the embedded software contained in it. The target device is initialized to be visible for LKM 202.
[33] LKM side Authorization process 301 in FIG.3 depicts the authorization performed by the LKM to validate the target device as authentic. The LKM searches for the target device as shown by 302 in the FIG.3. The LKM opens secure channel 303; in the event of the LKM not being successful in opening the secure channel as described hereinabove, the authorization process returns to searching for target devices as shown by 302 of FIG.3. If the LKM is successful in opening the secure channel to the target device, the target device checks for the said secure channel as shown by 203 in FIG. 2. In the event of the said target device not being successful in detecting the said secure channel, the above mentioned process to wait for the secure channel to be opened by LKM 203 is repeated as shown by the loop in FIG. 2.
[34] The method described herein involves the Digital Signatures of the target side executable image and target side RAM, which are henceforth depicted as DSIG_img and DSIG_RAM respectively. [35] After the LKM opens a secure communication channel to the target device, the said target device generates a Digital Signature of the RAM (DSIGJRAM) as shown by 204 in FIG.2. The LKM, after being successful in opening the secure channel, checks if the DSIG_RAM packet is received from the target as shown by 304 in FIG.3. If the DSIG_RAM packet is not received from the target, the LKM checks if the stipulated time for it to wait for the said DSIG-RAM has exceeded as shown in Timeout 305. If the Timeout 305 is affirmative, which is, the stipulated time for the LKM to wait for the DSIG-RAM has exceeded, said LKM sends a Negative Acknowledgment (NACK) to the target and closes the session as shown 309. The LKM then searches for other devices 302 as shown in FIG.2. If the said stipulated time has not been exceeded, the LKM searches for the DSIG_RAM from the target again as indicated by the loop in FIG.3.
[36] The target device further generates the Digital Signature of the target side executable image (DSIG_img) which is encrypted with the aforementioned DSIG_RAM and sends it to the LKM as shown by 205 in FIG.2. The LKM waits for the DSIG_img after receiving the DSIG_RAM from the target device as shown by 306 in FIG. 3. If the DSIG_img packet is not received from the target, the LKM checks if the stipulated time is exceeded as shown in Timeout 307. If the Timeout 307 is affirmative, which is, the stipulated time for the LKM to wait for the DSIG_img has been exceeded, then the LKM sends a NACK to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices 302 as shown in the FIG. 3. If the stipulated time has not been exceeded, then LKM waits for the DSIG_img packet from the target again as indicated by the loop in FIG.3.
[37] The LKM decrypts the DSIGJmg using the DSIG_RAM received from the target as shown above, and compares it with the computed DSIG 308 in FIG.3. In the event wherein the comparison of the decrypted DSIG_img and Computed DSIG does not match, the LKM sends a Negative Acknowledgment (NACK) to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices
302 as shown in the FIG. 3. If the said decrypted DSIG_img and the said Computed DSIG of the image match, the LKM sends Acknowledgment (ACK) to the target device.
[38] The above mentioned ACK and NACK are encrypted executable code wherein if the target device is unable to decrypt it, the embedded software would execute an illegal instruction, which triggers execution of code to self destructs itself. The ACK/NACK is thus used to authenticate the target device.
[39] The target device checks if the above mentioned ACK or NACK is received 206, if the said ACK/NACK is not received, the target device perform the above mentioned check again; if the ACK/NACK is received, the target device decrypts and executes the ACK/NACK code as shown by 207 in FIG.2. In the event of the ACK/NACK code being decrypted wrongly, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by 208 in FIG.2.
[40] If the target device decrypts the ACK correctly it can proceed to the next step of waiting for the encrypted Lkey from LKM 209. The LKM generates the Lkey, updates the database, encrypts the said Lkey using the aforementioned DSIG-RAM; the said encrypted Lkey is sent to target device as shown by 310. The target device checks if it has received the encrypted Lkey packet from the LKM iteratively until the said packet is received as shown 209.
[41] The target device saves the Lkey and the device identifier, decrypts the above mentioned Lkey packet using DSIG_img and sends the decrypted (transformed)
Lkey packet to the LKM as shown by 210.
[42] The LKM checks if it has received the Lkey 311, which is decrypted using
DSIG_img as mentioned above by the target device. If the said decrypted (transformed) Lkey is not received from the target, the LKM checks if the stipulated time is exceeded as shown in Timeout 312. If the Timeout 312 is affirmative, which is the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, the LKM sends NACK and closes the session 309 and the authorization process returns to searching for target devices as in 302 of FIG.3. If the stipulated time has not been exceeded, then LKM waits for the said decrypted Lkey from the target again as indicated by the loop in FIG.3.
[43] If the LKM receives the said decrypted (transformed) Lkey it compares it with the locally computed Lkey as shown by 313. In the event wherein the comparison of the decrypted Lkey and computed Lkey does not match, the LKM sends a NACK to the target and closes the session as shown by 309 in FIG.3. The LKM then scans for other devices 302 as shown in the FIG.3. If the decrypted (transformed) Lkey and computed Lkey match, the LKM sends an ACK to the target device as shown in FIG. 3.
[44] The target device checks if the above mentioned ACK or NACK is received by it as shown by 211. If the said ACK/NACK is not received the target device waits till the
ACK/NACK is received, then the target device decrypts and executes the
ACK/NACK code as shown by 212. In the event of the ACK/NACK code being decrypted wrongly the embedded software in the target executes an illegal instruction which triggers the execution of code to self destruct itself as shown by 213.
[45] If the above mentioned ACK is decrypted correctly, the target device blows the fuse and sends SUCCESS message to the LKM and performs RESET as shown by 214.
[46] The LKM checks if it has received the SUCCESS message as mentioned above by the target device. If the said SUCCESS message is not received from the target, the LKM checks if the stipulated time is exceeded as shown in Timeout 316. If the Timeout 316 is affirmative, which is, if the stipulated time for the LKM to wait for the said SUCCESS has exceeded, then LKM sends a NACK to the target and closes the session as shown by 309 in FIG. 3. The LKM then scans for other devices 302 as shown in the FIG. 3. If the stipulated time has not been exceeded, then LKM waits for the SUCCESS message from the target again as indicated by the loop in FIG.3. [47] If the LKM gets the SUCCESS sent by the target device, the session is closed as shown by 316 in FIG.3 and the LKM continues to scan for other devices for authorization 302 as shown in FIG.3.
[48] The block diagram in FIG.4 illustrates the handshake between the LKM and the target device over secure communication channels. The License key manager 401 is an authorization device which authorizes the target device 402 to execute the software code contained in it.
[49] The authorization of the said target device 402 over a secure communication channel is explained with reference to FIG.2 and FIG.3 hereinabove.
EXAMPLE
[50] FIG.5 illustrates the overview of the authorization mechanism wherein the Bluetooth devices 602 and 603 containing the embedded software is authorized to use the valid software using the Bluetooth License Key manager (LKM) 604, wherein the LKM 604 is a secure tamper-proof device running secure algorithms and it maintains information in a non-volatile memory including but not limited to the license information which includes but is not limited to the number of devices authorized, the number of the valid licenses still remaining, valid customer and application information. The said LKM 604 can include but not limited to a computing device. The said non-volatile memory is unreadable from outside the said Bluetooth devices 602 and 603. The aforementioned information is maintained in a tamper-proof, nonvolatile, secure embedded database.
[51] The Bluetooth devices 602 and 603 are programmed by 601 in FIG.6. The power up
501 of the Bluetooth devices 602 and 603 shows the initial powering up of the Bluetooth devices 602 and 603; 502 depicts the basic initialization process in the
Bluetooth devices 602 and 603. The Bluetooth devices 602 and 603 check if the
License key (Lkey) has been received from the LKM 604 as shown by 503. [52] If the Lkey is not received, the authorization process 504 is initiated as shown by FIG.5. After the completion of the authorization process 504, the basic initialization of the target device 502 is performed as shown in the figure. The aforementioned LKM 604 checks the validity of the Bluetooth devices 602 and 603 as shown by step
505. If the Bluetooth devices 602 and 603 are not valid, the embedded software on the said Bluetooth devices 602 and 603 executes an illegal instruction which triggers execution of code to self destruct itself as shown by 506. If the said Bluetooth devices 602 and 603 certify themselves as valid as shown in the figure, the Lkey is further validated wherein regular run-time checks are performed at random points in the application and stack codes. If the said Lkey is not validated, the embedded software on the said target device executes an illegal instruction which triggers execution of code to self destruct itself as shown by508. If the said Lkey is validated, the Bluetooth devices 602 and 603 containing the embedded software continue to operate normally as shown by 509 in FIG. 5.
[53] Every embedded software distribution is accompanied by LKM 604 thus controlling the number of Bluetooth devices 602 and 603 manufactured containing the said software
[54] The authorization mechanism wherein the Bluetooth devices 602 and 603 containing the embedded software is validated to use the embedded software by the LKM 604 as shown by FIG.5 is explained in conjunction with the process performed by the Bluetooth devices 602 and 603 and the LKM 604 as described in FIG.7 and FIG.8 ' respectively.
[55] The flowchart in FIG.7 shows the Bluetooth side authorization process. The flowchart in FIG.8 shows the authorization process performed by the LKM 604.
[56] The Bluetooth side authorization process shown by step 701 in FIG.7 depicts the process performed by the Bluetooth devices 602 and 603 to get validation of Bluetooth devices 602 and 603 to get validation from the said LBGVI 604 to use the embedded software contained in it.
[57] The Bluetooth devices 602 and 603 are initialized to be visible for LKM 604. LKM side authorization process shown by step 801 in FIG.8 depicts the authorization performed by the LKM 604 to validate the Bluetooth devices 602 and 603 as authentic.
[58] The LKM 604 searches for the Bluetooth devices 602 and 603 where the Bluetooth chip is programmed with user defined "Security Class of Devices" (Security CoD) as shown by step 802 in the figure 8. The LKM side then searches for the next device ID of the Bluetooth devices as shown by step 803. After the end of the list the
LKM again starts scanning for the next list of devices as shown by step 804.
[59] If the Bluetooth devices 602 and 603 are detected, the LKM 604 opens secure SPP channel with the Bluetooth devices 602 and 603 as shown by step 805. In the case of the LKM 604 not being successful in opening the secure SPP channel to the Bluetooth devices 602 and 603, the authorization process returns to searching for target devices as in 802 of FIG.8.
[60] If the LKM is successful in opening the secure channel to the target device, the target device checks for the said secure SPP channel as shown as 703 in FIG. 7. In the event of the said Bluetooth devices 602 and 603 not being successful in detecting the said secure SPP channel, the above mentioned process to wait for the secure SPP channel to be opened by LKM 604 is repeated as shown by the loop for 703 in
FIG. 7.
[61] The method described herein involves the Digital Signatures of the Bluetooth side executable image and RAM which are depicted as DSIG_img and DSIG_RAM henceforth. [62] If the secure channel opened by the said LKM is detected by the Bluetooth devices
602 and 603, then the said Bluetooth devices 602 and 603 generate a Digital Signature of the RAM (DSIG_RAM) and send it to LKM 604 as shown by 704 in FIG.7.
[63] The LKM, after being successful in opening the secure channel, checks if the DSIG-RAM packet is received from the Bluetooth devices 602 and 603 as shown by 806 in FIG.8.
[64] If the DSIG_RAM packet is not received from the Bluetooth devices 602 and 603, the LKM 604 checks if the time stipulated for it to wait for the said DSIG_RAM has exceeded as shown in Timeout 807. If the Timeout 807 is affirmative, where the stipulated time for the LKM to wait for the DSIG_RAM has exceeded, then LKM sends a Negative acknowledgment (NACK) to the Bluetooth devices 602 and 603 and closes the session as shown by 811 in FIG.8. The LKM then searches for other devices as shown by 803 in FIG. 8. If the stipulated time has not been exceeded, the LKM waits for the DSIG_RAM from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
[65] The Bluetooth devices 602 and 603 further generates the Digital Signature of the
Bluetooth device side executable image (DSIG_img) which is encrypted with the aforementioned DSIG-RAM and sent to LKM 604 as shown by 705 in FIG.7.
[66] The LKM waits for the DSIGJmg after receiving the DSIG_RAM from the Bluetooth devices 602 and 603 as shown by 808 in Fig. 8.
[67] If the DSIG_img packet is not received from the Bluetooth devices 602 and 603, the
LKM checks if the stipulated time is exceeded as shown in Timeout 809. If the
Timeout 809 is affirmative, which is the stipulated time for the LKM to wait for the DSIG_img has exceeded, the LKM sends a NACK to the Bluetooth devices 602 and
603 and closes the session as shown by 811 in FIG. 8. The LKM then scans for other devices 803 as shown in the FIG. 8. If the stipulated time has not been exceeded, the LKM waits for the DSIG_img packet from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8,
[68] The LKM decrypts the DSIG_img using the DSIG_RAM received from the Bluetooth devices 602 and 603 as shown above, and compares it with the locally computed DSIG as shown by 810 in FIG.8. In the event wherein the comparison of the decrypted DSIG_img and Computed DSIG does not match, the LKM sends a
Negative acknowledgment (NACK) to the Bluetooth devices 602 and 603 and closes the session as shown by 811 in FIG. 8. The LKM then scans for other devices 803 as shown in the FIG. 8. If the encrypted DSIG_img and locally computed DSIG match, then LKM sends acknowledgment (ACK) to the Bluetooth devices 602 and 603 device.
[69] The above mentioned ACK and NACK are encrypted executable code wherein if the target device is unable to decrypt it, the embedded software would execute an illegal instruction which triggers execution of code to self destruct itself. The ACK/NACK is thus used to authenticate the target device.
[70] The Bluetooth devices 602 and 603 check if the above mentioned ACK or NACK is received by it 806, if the said ACK/NACK is not received, the Bluetooth devices
602 and 603 perform the above mentioned check again as shown by the loop in
FIG.2; if the ACK/NACK received, the Bluetooth devices 602 and 603 decrypt and execute the ACK/NACK code as shown by 807.
[71] In the event of the ACK/NACK code being decrypted wrongly the embedded software in the Bluetooth devices 602 and 603 would execute an illegal instruction, which triggers execution of code to self destruct itself as shown by 708.
[72] If the Bluetooth devices 602 and 603 decrypt the ACK correctly, the LKM generates the Lkey, updates the database and encrypts the said Lkey using the aforementioned
DSIGJRAM; the said encrypted Lkey is sent to Bluetooth devices 602 and 603 devices as shown by 812 in FIG.8. [73] The Bluetooth devices 602 and 603 checks if it has received the encrypted Lkey packet from the LKM iteratively until the said packet is received as shown by 709 in FIG.7.
[74] The Bluetooth devices 602 and 603 saves the said Lkey and BTID3 decrypts the above mentioned Lkey packet using DSIG^img and sends the decrypted Lkey packet to the LKM as shown by 710 in FIG.7.
[75] The LKM checks if it has received the Lkey which is decrypted using DSIG_img
813 as mentioned above by the Bluetooth devices 602 and 603. If the said encrypted Lkey is not received from the Bluetooth devices 602 and 603, the LKM checks if the stipulated time is exceeded as shown in Timeout 814. If the Timeout 814 is affirmative, which is the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, the LKM sends a NACK closes the session as shown by 811 in
FIG. S.The authorization process returns to searching for Bluetooth devices as shown by 803 of FIG.8. If the stipulated time has not been exceeded, then LKM waits for the said decrypted Lkey from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
[76] If the LKM receives the said decrypted Lkey, it compares it with the locally computed Lkey as shown by 815. In the event wherein the comparison of the decrypted Lkey and locally computed Lkey does not match, the LKM sends a NACK to the Bluetooth devices 602 and 603 and closes the session 811 in FIG. 8. The LKM then scans for other devices 803 as shown in the FIG. 8. If the encrypted
Lkey and locally computed Lkey match, the LKM sends an ACK to the Bluetooth devices 602 and 603 as shown in FIG. 8.
[77] The Bluetooth devices 602 and 603 checks if the above mentioned ACK or NACK is received by it as shown by 711, if the said ACK/NACK is not received, the
Bluetooth devices 602 and 603 perform the above mentioned check again; if the
ACK/NACK received, the Bluetooth devices 602 and 603 decrypts and executes the ACK/NACK code as shown by 712 in FIG.7. In the event of the ACK/NACK code being decrypted wrongly, the embedded software in the Bluetooth devices 602 and 603 would execute an illegal instruction which triggers execution of code to self destruct itself as shown by 713 in FIG.7.
[78] If the above mentioned ACK is encrypted correctly, the Bluetooth devices 602 and 603 blows the fuse and sends SUCCESS message to the LKM and performs RESET as shown by 714.
[79] The LKM checks if it has received the SUCCESS message as mentioned above from the Bluetooth devices 602 and 603 as shown by 816 in FIG.8. If the said SUCCESS message is not received from the Bluetooth devices 602 and 603, the LKM checks if the stipulated time is exceeded as shown in Timeout 817. If the Timeout 817 is affirmative, which is, if the stipulated time for the LKM to wait for the said encrypted Lkey has exceeded, then LKM sends a NACK to the Bluetooth devices
602 and 603 and closes the session as shown by 811 in FIG. 8. The LKM then scans for other devices 803 as shown in the FIG. 8. If the stipulated time has not been exceeded, then LKM waits for SUCCESS message from the Bluetooth devices 602 and 603 again as indicated by the loop in FIG.8.
[80] If the LKM gets the SUCCESS sent by the Bluetooth devices 602 and 603, the session is closed as shown by 818 in FIG.8 and the LKM continues to scan for other devices for authorization 803 as shown in FIG.8.
[81] Another example with relation to the block diagram of FIG.9 shows IP protection technique which uses Internet for the secure communication channel. The entity on which code is present 901 and 902 are authorized by the managing entity on the source side 904. The authorization is done either through wired or wireless medium over the Internet 903.
[82] The authorization of the target device by the LKM can be done using the secure communication channels including but not limiting to Bluetooth, Internet, WLAN, Ultra Wide Band (UWB), WiMAX, GSM, CDMA5 USB, and IEEE1394. Further, the communication channels can include but not limited to wired and wireless communication channels which can be secure or insecure.
[83] Although the present invention has been described with particular reference to specific examples, variations and modifications of the present invention can be effected within the spirit and scope of the following claims.

Claims

Claims We claim:
1. A system to protect embedded software which comprises of:
a. a target device comprising embedded software to be protected;
b. a License Key Manager to authorize said target device; and
c. a secure communication channel for communication between said License Key Manager and said target device.
2. A system to protect embedded software as claimed in claim 1, wherein said target device comprises of non-volatile memory to store information, the non-volatile memory being unreadable from outside said target device
3. A system to protect embedded software as claimed in claim 1, wherein said target device is adapted to communicate with said License Key Manager for authorization over a secure channel.
4. A system to protect embedded software as claimed in claim 1, wherein said target device is adapted to self destroy itself and prevent any further use of said target device by executing an illegal instruction which triggers the execution of code to self destruct ■ itself.
5. A system to protect embedded software as claimed in claim 1, wherein said License Key Manager is a computing device.
6. A system to protect embedded software as claimed in claim 1 , wherein said License
Key Manager comprises of non- volatile memory to store information.
7. A system to protect embedded software as claimed in claim 1, wherein said License Key Manager is adapted to authorize said target device.
8. A system to protect embedded software as claimed in claim 1, wherein said License Key Manager is adapted to communicate with said target device through a secure communication channel.
9. A system to protect embedded software as claimed in claim 7, wherein said License Key Manager comprises of a secure embedded database of license information.
10. A system to protect embedded software as claimed in claim 9, wherein the secure embedded database of license information comprises of:
a. number of target devices authorized;
b. number of valid licenses remaining;
c. customer name;
d. application name;
e. version information;
f. digital signature of the executable image; and
g. latest generated Lkey.
11. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is Internet.
12. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is Bluetooth.
13. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is WLAN.
14. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is UWB.
15. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is WiMAX.
16. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is GSM.
17. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is CDMA.
18. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is USB.
19. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is IEEE 1394.
20. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is RS232.
21. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is RS422.
22. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is I2C.
23. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is CAN.
24. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is Ethernet.
25. A system to protect embedded software as claimed in claim 1, wherein the secure communication channel is Fiber Channel.
26. A method to protect embedded software comprising:
a. powering up a target device;
b. initializing said target device to be visible to the License Key Manager;
c. said License Key Manager scanning for a target device;
d. opening a secure communication channel by said License Key Manager;
e. said target device generating digital signature of RAM of the target device;
f. said target device transferring the said digital signature of RAM to said License Key Manager;
g. said target device generating digital signature of target side executable image;
h. said target device encrypting the said digital signature of target side executable image using digital signature of RAM of said target device;
i. said target device transferring the said encrypted digital signature of target side executable image to said License Key Manager; j. said License Key Manager decrypting the said encrypted digital signature of target side executable image by using the digital signature of RAM of said target device;
k. said License Key Manager comparing the said digital signature of target side executable image with the locally computed digital signature of image of said target device;
1. said License Key Manager sending an acknowledgment when the said comparison has matched;
m. said License Key Manager generating Lkey;
n. said License Key Manager encrypting Lkey using the digital signature of RAM of said target device;
o. said License Key Manager updating the database;
p. said License Key Manager transferring the encrypted Lkey to said target device;
q. said target device saving the said Lkey and the device identifier;
r. said target device decrypting the encrypted Lkey using digital signature of target side executable image;
s. said target device transferring the said Lkey to said License Key Manager;
t. said License Key Manager comparing the said Lkey with the computed Lkey;
u. said target device sending success message to said License Key Manager; v. said target device blowing fuse and performs reset; and
w. said License Key Manager closing the session after receiving the success
. message.
27. A method to protect embedded software as claimed in claim 26, wherein powering up said target device comprises:
a. initializing said target device;
b. checking if an Lkey is already received from said License Key Manager;
c. invoking the authorization process if Lkey is not already received and receiving an Lkey from said License Key Manager;
d. authenticating the validity of Lkey wherein said target device performs runtime checks at random points in the application and stack codes;
e. invoking self destruction instructions if Lkey is not a valid Lkey; and
f. said target device continuing to operate if Lkey is found to be a valid Lkey.
28. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager waits for a pre-configurable period of time for receiving the digital signature of RAM of said target device after which the License Key
Manager sends a negative acknowledgment to the target and closes the session.
29. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager waits for the encrypted digital signature of target side executable image for a pre-configurable period of time after which the License Key
Manager sends a negative acknowledgment message to said target device and closes the session.
30. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager decrypts said encrypted digital signature of target side executable image.
31. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager sends a negative acknowledgment message to said target device and closes the session when the said decrypted digital signature of the target side executable image and the locally computed digital signature of the target side executable image do not match.
32. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager waits for the decrypted (transformed) Lkey for a pre- configurable period of time after which the License Key Manager sends a negative acknowledgment message to said target device and closes the session.
33. A method for IP protection for embedded software as claimed in claim 26, wherein said License Key Manager sends a negative acknowledgment message to said target device and closes the session if the received Lkey and the computed Lkey do not match.
34. A method to protect embedded software as claimed in claim 26, wherein said License Key Manager controls the number of target devices manufactured according to the number of authorized devices and the number of valid licenses remaining.
35. A method to protect embedded software as claimed in claim 26, wherein said target device sends a success message on receiving an acknowledgment message from said License Key Manager.
36. A method to protect embedded software as claimed in claim 26, wherein the acknowledgment and negative-acknowledgment is sent by the License Key Manager as encrypted executable code.
37. A method to protect embedded software as claimed in claim 36, wherein the embedded software in . the said target device would execute an illegal instruction, which triggers execution of code to self destruct itself if the acknowledgment or negative-acknowledgment is not decrypted and executed correctly by said target device.
PCT/IN2006/000350 2006-09-13 2006-09-13 Protection scheme for embedded software WO2008032332A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IN2006/000350 WO2008032332A1 (en) 2006-09-13 2006-09-13 Protection scheme for embedded software

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2006/000350 WO2008032332A1 (en) 2006-09-13 2006-09-13 Protection scheme for embedded software

Publications (1)

Publication Number Publication Date
WO2008032332A1 true WO2008032332A1 (en) 2008-03-20

Family

ID=37820588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2006/000350 WO2008032332A1 (en) 2006-09-13 2006-09-13 Protection scheme for embedded software

Country Status (1)

Country Link
WO (1) WO2008032332A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014028663A2 (en) * 2012-08-15 2014-02-20 Synopsys, Inc. Protection scheme for embedded code
CN110909316A (en) * 2019-11-14 2020-03-24 武汉正维电子技术有限公司 Encryption protection method of single chip microcomputer software and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6000030A (en) * 1996-06-20 1999-12-07 Emc Corporation Software fingerprinting and branding
WO2002065258A2 (en) * 2001-02-13 2002-08-22 Qualcomm Incorporated Method and apparatus for authenticating embedded software in a remote unit over a communications channel
US20050044546A1 (en) * 2003-07-03 2005-02-24 Euroform A/S Method of allowing printing from a network attached device
WO2006050543A1 (en) * 2004-11-09 2006-05-18 Kapsch Trafficcom Ag Method and system for the user-specific initialization of identification devices in the field

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6000030A (en) * 1996-06-20 1999-12-07 Emc Corporation Software fingerprinting and branding
WO2002065258A2 (en) * 2001-02-13 2002-08-22 Qualcomm Incorporated Method and apparatus for authenticating embedded software in a remote unit over a communications channel
US20050044546A1 (en) * 2003-07-03 2005-02-24 Euroform A/S Method of allowing printing from a network attached device
WO2006050543A1 (en) * 2004-11-09 2006-05-18 Kapsch Trafficcom Ag Method and system for the user-specific initialization of identification devices in the field

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014028663A2 (en) * 2012-08-15 2014-02-20 Synopsys, Inc. Protection scheme for embedded code
WO2014028663A3 (en) * 2012-08-15 2014-05-01 Synopsys, Inc. Protection scheme for embedded code
US9514064B2 (en) 2012-08-15 2016-12-06 Synopsys, Inc. Protection scheme for embedded code
US9715463B2 (en) 2012-08-15 2017-07-25 Synopsys, Inc. Protection scheme for embedded code
US10678710B2 (en) 2012-08-15 2020-06-09 Synopsys, Inc. Protection scheme for embedded code
CN110909316A (en) * 2019-11-14 2020-03-24 武汉正维电子技术有限公司 Encryption protection method of single chip microcomputer software and storage medium
CN110909316B (en) * 2019-11-14 2023-05-09 武汉正维电子技术有限公司 Encryption protection method for singlechip software and storage medium

Similar Documents

Publication Publication Date Title
TWI384381B (en) Upgrading a memory card that has security mechanisms that prevent copying of secure content and applications
US7240201B2 (en) Method and apparatus to provide secure communication between systems
US20190075112A1 (en) Networked access control system
US7205883B2 (en) Tamper detection and secure power failure recovery circuit
US7215771B1 (en) Secure disk drive comprising a secure drive key and a drive ID for implementing secure communication over a public network
ES2236530T3 (en) SECURITY METHOD FOR AN ELECTRONIC DEVICE, A SECURITY SYSTEM AND AN ELECTRONIC DEVICE.
EP2080148B1 (en) System and method for changing a shared encryption key
US8000467B2 (en) Data parallelized encryption and integrity checking method and device
US8321924B2 (en) Method for protecting software accessible over a network using a key device
US20030065934A1 (en) After the fact protection of data in remote personal and wireless devices
US20070028118A1 (en) System and method for encrypted smart card pin entry
CN100495421C (en) Authentication protection method based on USB device
CN113545006A (en) Remote authorized access locked data storage device
CN109035519B (en) Biological feature recognition device and method
CN101682628A (en) Secure communications
CN101520832A (en) System and method for verifying file code signature
KR20100080031A (en) A method for firmware updating in remote
JP4833745B2 (en) Data protection method for sensor node, computer system for distributing sensor node, and sensor node
CN104868998A (en) System, Device, And Method Of Provisioning Cryptographic Data To Electronic Devices
GB2432436A (en) Programmable logic controller peripheral device
US7912788B2 (en) Mutual authentication system and method for protection of postal security devices and infrastructure
US20080000971A1 (en) Method for customizing customer identifier
US20040255136A1 (en) Method and device for protecting information against unauthorised use
US20050246285A1 (en) Software licensing using mobile agents
KR20190036779A (en) Method and system for secure firmware update

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06809946

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06809946

Country of ref document: EP

Kind code of ref document: A1