Link key injection mechanism for personal area networks
Claim Score by NHIP
Abstract
According to one embodiment, a method is disclosed. The method includes generating a link key at a secure component within a first personal area network device and injecting the link key into a protocol stack component database within the first device. The link key may further be transmitted to a second device. Other embodiments are described and claimed.

Term
Projected expiry 7 June 2028.
- Priority and filed
- Published
- Today
- Projected expiry
20 claims: 3 independent, 17 dependent
- 1Broadest claimClaim Score 89, very broad(NHIP)A method comprising:generating a link key at a secure component within a first personal area network device;and injecting the link key into a protocol stack component database within the first device.
- 9A computer system comprising:a Bluetooth stack having a service database;a security manager having a generator to initiate the generation of a link key;a security component to generate the link key;and a Bluetooth engine having a link key injection module to inject the link key into the service database.
- 15An article of manufacture including one or more computer readable media that embody a program of instructions, wherein the program of instructions, when executed by a processing unit, causes the processing unit to perform the process of:generating a link key at a secure component within a first personal area network device;and injecting the link key into a protocol stack component database within the first device.
Independent claims3
38 paragraphs in 4 sections, as filed
FIELD OF THE INVENTION
0001The present invention relates to computer systems; more particularly, the present invention relates to security for personal area networks.
BACKGROUND
0002Currently, Bluetooth and the emerging (ultra-wide band) UWB are the leading protocols in the market for local, short-range, and personal area networks. However, one of the most challenging aspects of such protocols is weak security. For example, the weakest security point in Bluetooth is the fact that link and encryption keys are derived from a PIN code that a user/operator of Bluetooth coupled devices is expected to physically/manually enter during device-pairing. The PIN code's size ranges from 4 to 16 Octets. Such flexibility usually leads to device-users/operators entering the smallest possible PIN code, which in turn results in weak link and encryption keys.
BRIEF DESCRIPTION OF THE DRAWINGS
0003The invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:
0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates one embodiment of a network;
0005<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of one embodiment of a computer system;
0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates another embodiment of a computer system.
0007<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram for one embodiment for providing security for a Bluetooth link; and
0008<figref idref="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a user interface screenshot.
DETAILED DESCRIPTION
0009A security method for personal area networks and short range radio systems is described. The method includes pairing two Bluetooth enabled devices. Next, a link key is generated at a first device. A public/private key pair is then generated and the public key is exchanged between the first device and a second device using standard Bluetooth data exchange.
0010Subsequently, proof of ownership is to be established by having a user prove that the user is the owner of the first device and the second device. The link key is then encrypted and transmitted from the first device to the second device, where it is decrypted. The link key is injected to a database at both the first device and the second device.
0011In the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
0012Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
0013Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
0014It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
0015The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
0016The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
0017The instructions of the programming language(s) may be executed by one or more processing devices (e.g., processors, controllers, control processing units (CPUs),
0018<figref idref="DRAWINGS">FIG. 1</figref> illustrates one embodiment of a network <b>100</b>. Network <b>100</b> includes a computer system <b>110</b> and a computer system <b>120</b> coupled via a transmission medium <b>130</b>. In one embodiment, computer system <b>110</b> operates as a source device that transmits data to computer system <b>120</b>, operating as a receiving device. The data may be, for example, a file, programming data, an executable, voice data, or other digital objects. The data is sent via data transmission medium <b>130</b>.
0019According to one embodiment, network <b>100</b> is a personal area network, and data transmission medium <b>130</b> is implemented as Bluetooth or ultra-wide band (UWB), short range radio, etc. In a further embodiment, computer system <b>110</b> may be a personal computer system, while computer system <b>120</b> is a wireless handheld device.
0020<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of one embodiment of a computer system <b>200</b>. Computer system <b>200</b> may be implemented as computer system <b>110</b> or computer system <b>120</b> (both shown in <figref idref="DRAWINGS">FIG. 1</figref>). Computer system <b>200</b> includes a central processing unit (CPU) <b>202</b> coupled to bus <b>205</b>. A chipset <b>207</b> is also coupled to bus <b>205</b>. Chipset <b>207</b> includes a memory control hub (MCH) <b>210</b>. MCH <b>210</b> may include a memory controller <b>212</b> that is coupled to a main system memory <b>215</b>. Main system memory <b>215</b> stores data and sequences of instructions that are executed by CPU <b>202</b> or any other device included in system <b>200</b>.
0021In one embodiment, main system memory <b>215</b> includes dynamic random access memory (DRAM); however, main system memory <b>215</b> may be implemented using other memory types. For example, in some embodiments, main system memory <b>215</b> may be implemented with a non-volatile memory.
0022According to one embodiment, MCH <b>210</b> also includes a trusted platform module (TPM) <b>212</b>. TPM <b>212</b> includes protected registers <b>120</b> that are writable by commands that may only be initiated by trusted microcode in CPU <b>202</b>. Protected microcode is microcode whose execution may be initiated by authorized instruction(s) and/or by hardware that is not controllable by unauthorized devices. The protected registers may include a register to enable or disable the use of a protected table within main memory <b>115</b>.
0023MCH <b>210</b> is coupled to an input/output control hub (ICH) <b>240</b> via a hub interface. ICH <b>240</b> provides an interface to input/output (I/O) devices within computer system <b>200</b>. For example ICH <b>240</b> may be coupled to a transceiver <b>250</b>. Transceiver <b>250</b> facilitates a personal area network between computer system <b>200</b> and a remote device. According to one embodiment, transceiver <b>250</b> communicates data between computer system <b>110</b> and computer system <b>120</b> via a Bluetooth interface.
0024As discussed above, a problem with the Bluetooth interface involves security in the link. The current Bluetooth security model involves a PIN code being used to generate a link key. The link keys are subsequently exchanged and agreed between the devices in the open prior to encryption being enabled. The encryption keys are then derived from link keys. When encryption is used the encryption key is used.
0025One issue with the current security model is that the PIN size ranges between 4 and 16 digits. However, users typically use the shortest or even default PIN (e.g., 0000). Such PINs can be guessed by a dictionary attack. In addition, a PIN can be sniffed during the pairing process. Another issue is that the link key may be intercepted during key exchange and agreement phase. Further, the strength of encryption is directly tied to PIN length.
0026According to one embodiment, a secure link key generation and exchange mechanism is provided to generate a link key outside of a Bluetooth stack and to inject the key into the stack. <figref idref="DRAWINGS">FIG. 3</figref> illustrates one embodiment of modules within computer system <b>200</b> implemented to perform link key generation and exchange.
0027Referring to <figref idref="DRAWINGS">FIG. 3</figref>, computer system <b>200</b> includes a user interface (UI) <b>310</b>, a security manager <b>320</b>, a connection manager <b>330</b>, Bluetooth engine <b>340</b> and Bluetooth stack <b>350</b>. UI <b>310</b> enables user interaction with computer system <b>200</b>. Security manager <b>320</b> provides security for the Bluetooth interface between devices. For example, security manager <b>320</b> includes a link key generator to initiate the generation of a link key, and to store the key once generated.
0028In one embodiment, the link key is generated at TPM <b>212</b>. However in another embodiment, the link key is generated using cryptographic software such as Microsoft Cryptographic Application Program Interface (MS CAPI) included within security manager <b>320</b>. Security manager <b>320</b> may also include a policy engine and an access control module, as well as other security modules.
0029Connection manager <b>330</b> manages the interface between two devices coupled via Bluetooth. Bluetooth engine <b>340</b> is an application program interface (API) that performs various functions to initiate Bluetooth communication between devices. For instance, Bluetooth engine <b>340</b> includes a proximity detection module to detect whether another Bluetooth enabled device is in close proximity to computer system <b>200</b>.
0030Further, Bluetooth engine <b>340</b> includes an auto-pairing module to pair computer system <b>200</b> with a detected device, and a link key injection module to inject a generated link key into a database (not shown) within Bluetooth stack <b>350</b>. According to one embodiment, the link key is also stored in security manager <b>320</b> as discussed above. Bluetooth stack <b>350</b> implements a Bluetooth protocol stack, which performs functions such as the Logical Link Control and Adaptation Layer Protocol (L2CAP) and Host Controller Interface (HCI), as well as other functions.
0031<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram of one embodiment of providing link key generation and end exchange. At processing block <b>410</b>, device pairing is initiated at the auto pairing module within Bluetooth engine <b>340</b>. In one embodiment, the devices to be paired are to be in proximity and in a discoverable mode. Further, unlike the traditional pairing mechanism (e.g., where the PIN code must be physically entered by the user/operator), the pairing devices do not need to be in a secure location during pairing because PIN interception is not a concern.
0032At processing block <b>420</b>, link key generation is performed at computer system <b>200</b>. As discussed above the security manager initiates the generation of the link key either by having a hardware device, such as TPM <b>212</b> generate the key, or having the key generated via MS CAPI. In one embodiment, the new link key is a 128 bit key.
0033After the link key has been generated, the link key is to be provided to the device paired with computer system <b>200</b>. However, prior to transmitting the link key, the secure transmission of the link is to be ensured. Thus at processing block <b>430</b>, a public/private key pair is generated and the public key is exchanged using standard Bluetooth data exchange. In one embodiment, the public/private key pair is generated via Rivest, Shamir & Adleman (RSA) public key encryption technology.
0034At processing block <b>440</b>, proof of ownership is established. Proof of ownership involves a process of having a user prove that the user owns both devices being paired for Bluetooth connection. In one embodiment, a hash of the public key is displayed on the computer system <b>200</b>, the device, or both via UI <b>310</b>. The user is then prompted to select a valid value from a listing of values to prove ownership.
0035For example, UI <b>310</b> may display three sets of 6 digit numbers, where only one is correct (e.g., derived from the public keys, and the other two are random). The user is then prompted to select the correct signature on one or both of computer system <b>200</b> or the device. <figref idref="DRAWINGS">FIG. 5</figref> illustrates one embodiment of a display, at either computer system <b>200</b> or the paired device, requesting proof of ownership.
0036Referring back to <figref idref="DRAWINGS">FIG. 4</figref>, at decision block <b>445</b> it is determined whether the user has selected the correct value. If an incorrect value is selected by the user, the authentication fails and the user is informed via UI <b>310</b> that the process will be discontinued, processing block <b>448</b>. Otherwise, link key exchange is performed at processing block <b>450</b>. In one embodiment, the link key is signed at computer system <b>200</b> using the private key of computer system <b>200</b> and encrypted using the public key of the device. Subsequently, the encrypted link key is transmitted to the device. Upon receiving the encrypted link key, the link key is decrypted using the private key of the device. The signature is then verified. At processing block <b>460</b>, the link key is injected to a HCI key database at both computer system <b>200</b> and the device.
0037The above-described link key mechanism replaces the use of PIN codes to enhance the security as well as usability of Devices based on Short-Range Radio and Personal Area Networks. Further, the mechanism discloses the use of hardware-based cryptographic capabilities to generate link keys for Short-Range Radio communication.
0038Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.
Contents4
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| GB2452251A | Cited by | United Kingdom | Search report |
| KR20160021814A | Cited by | Republic of Korea | Search report |
| US7930728B2 | Cited by | United States of America | Search report |
| US2007150736A1 | Cited by | United States of America | Pre-grant |
| US8375207B2 | Cited by | United States of America | Applicant |
| US2009240814A1 | Cited by | United States of America | Pre-grant |
| US9698978B2 | Cited by | United States of America | Applicant |
| US8332643B2 | Cited by | United States of America | Applicant |
| US8670566B2 | Cited by | United States of America | Applicant |
| US2007136587A1 | Cited by | United States of America | Pre-grant |
| CN103490887A | Cited by | China | Search report |
| US8855310B2 | Cited by | United States of America | Applicant |
| US9768955B2 | Cited by | United States of America | Applicant |
| US2008005562A1 | Cited by | United States of America | Pre-grant |
| US2007266247A1 | Cited by | United States of America | Pre-grant |
| US2007162955A1 | Cited by | United States of America | Pre-grant |
| GB2452251B | Cited by | United Kingdom | Search report |
| US2014376721A1 | Cited by | United States of America | Pre-grant |
| US8005223B2 | Cited by | United States of America | Search report |
| US9749134B2 | Cited by | United States of America | Search report |
| EP2863578A4 | Cited by | European Patent Office (EPO) | Search report |
| US2007263872A1 | Cited by | United States of America | Pre-grant |
| US2001016909A1 | Cites | United States of America | Pre-grant |
| US2002173295A1 | Cites | United States of America | Pre-grant |
| US2003014372A1 | Cites | United States of America | Pre-grant |
| US2003018495A1 | Cites | United States of America | Pre-grant |
| US2003065918A1 | Cites | United States of America | Pre-grant |
| US2004083368A1 | Cites | United States of America | Pre-grant |
| US2004109441A1 | Cites | United States of America | Pre-grant |
| US2004124966A1 | Cites | United States of America | Pre-grant |
| US2004128509A1 | Cites | United States of America | Pre-grant |
| US2005021968A1 | Cites | United States of America | Pre-grant |
| US2005058294A1 | Cites | United States of America | Pre-grant |
| US2005226175A1 | Cites | United States of America | Pre-grant |
| US2005235141A1 | Cites | United States of America | Pre-grant |
| US2006053302A1 | Cites | United States of America | Pre-grant |
| US2006095772A1 | Cites | United States of America | Pre-grant |
| US2006133604A1 | Cites | United States of America | Pre-grant |
| US2006198448A1 | Cites | United States of America | Pre-grant |
| US2008320587A1 | Cites | United States of America | Pre-grant |
| US7123878B1 | Cites | United States of America | Pre-grant |
2 priority claims, no other members on record
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 16860305 | United States of America | A | |
| US20050168603 | – | – | – |
53 transactions on the USPTO file
Allowed after 2 non-final rejections, 1 final rejection and 1 RCE.
- Non-final rejections
- 2
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Maintenance Fee Reminder MailedREM. | REM. | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Mail Examiner's AmendmentMEX.A | MEX.A | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Correspondence Address ChangeC.ADB | C.ADB | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Notice of Informal or Non-Responsive AmendmentNINA | NINA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Informal or Non-Responsive Amendment after Examiner ActionA.I. | A.I. | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| New or Additional Drawing FiledC614 | C614 | |
| Additional Application Filing FeesADDFLFEE | ADDFLFEE | |
| A statement by one or more inventors satisfying the requirement under 35 USC 115, Oath of the ApplicOATHDECL | OATHDECL | |
| Applicant has submitted new drawings to correct Corrected Papers problemsCORRDRW | CORRDRW | |
| Notice Mailed--Application Incomplete--Filing Date AssignedINCD | INCD | |
| Cleared by L&R (LARS)L128 | L128 | |
| Referred to Level 2 (LARS) by OIPE CSRL198 | L198 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| New or Additional Drawing FiledC614 | C614 | |
| Initial Exam Team nnIEXX | IEXX |
7 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS | LAPS | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.)FEPP | FEPP | |
| Fee paymentFPAY | FPAY | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 20060291663
- Publication, DOCDB
- 2006291663
- Publication, EPODOC
- US2006291663
- Application
- 11168603
- Application, DOCDB
- 16860305
- Application, EPODOC
- US20050168603
Titles
- English
- Link key injection mechanism for personal area networks
Classification
- CPC, 8
- H04L9/0825
- H04L9/0877
- H04L63/0428
- H04L63/061
- H04L63/162
- H04L2209/80
- H04W12/04
- H04W12/033
- IPC, 1
- H04L9 00
- USPC, 1
- 380285000