Method and apparatus for providing an adaptable security level in an electronic communication

• US 10,637,869 B2
• Filed: 10/05/2018
• Issued: 04/28/2020
• Est. Priority Date: 04/13/2006
• Status: Active Grant

• Current Assignee: Blackberry Limited
• Original Assignee: Blackberry Limited
• Inventors: Struik, Marinus
• Primary Examiner(s): Pyzocha, Michael
• Application Number:
  US16/153,676
• Publication Number:
  US 20190052646A1
• Time in Patent Office: 571 Days
• CPC Class Codes: H04L 63/0227 Filtering policies mail message filtering H04L51/212
• CPC Class Codes: H04L 63/105 Multiple levels of security
• CPC Class Codes: H04L 63/12 Applying verification of the received information cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227

Abstract

A method of communicating in a secure communication system, comprises the steps of assembling a message at a sender, then determining a frame type, and including an indication of the frame type in a header of the message. The message is then sent to a recipient and the frame type used to perform a policy check.

Claims

1. A first device, comprising:

at least one hardware processor; and

a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the at least one hardware processor to perform operations comprising;

assembling a data stream, wherein the data stream comprise a frame, the frame having a header and data;

determining, by the first device, a security level for the frame;

incorporating, by the first device, in the header, an indication of a frame type and an indication of the security level; and

forwarding, by the first device, the frame to a second device, wherein the frame type is associated with a policy, and the policy indicates a minimum security level for the frame type, the frame being acceptable by the second device if the security level meets the minimum security level and the frame being not acceptable by the second device if the security level does not meet the minimum security level.

2. The first device according to claim 1, wherein the second device:

receives the frame;

determines the frame type from the header; and

correlates the frame type to the policy to determine if the frame is acceptable for at least one attribute of the frame.

3. The first device according to claim 2, wherein the second device accepts the frame if the policy is met, and rejects the frame if the policy is not met.

4. The first device according to claim 2, wherein the header includes a representation of a key and the policy indicates an acceptable frame type for the key.

5. The first device according to claim 2, wherein the policy indicates frame types vulnerable to an attack where one or more combinations of security features of the frame are present, and the second device rejects the frame if one of the one or more combinations is found.

6. The first device according to claim 2, wherein the indication of the security level includes one or more security bits indicative of the security level, and the second device extracts the security bits to determine the security level.

7. The first device according to claim 2, wherein the policy comprises a look up table correlating the frame type to the at least one attribute.

8. The first device according to claim 1 wherein the frame further comprises a footer comprising one or more bits representing an error code.

9. The first device according to claim 1 wherein the header comprises a key identifier, a representation of a key corresponding to the key identifier, and an originator for determining an acceptability of the frame type.

10. A second device, comprising:

at least one hardware processor; and

a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the at least one hardware processor to perform operations comprising;

receiving, at the second device and from a first device, a frame having a header and data, the header including an indication of a frame type and an indication of a security level;

determining, by the second device, the frame type from the header;

correlating, by the second device, the frame type to a policy, wherein the policy indicates a minimum security level for the frame type; and

determining, by the second device and based on the policy, whether to accept the frame type according to whether the security level meets the minimum security level.

11. The second device according to claim 10, the operations further comprising accepting the frame if the policy is met, and rejecting the frame if the policy is not met.

12. The second device according to claim 10, wherein the header includes a representation of a key and the policy indicates an acceptable frame type for the key.

13. The second device according to claim 10, wherein the policy indicates frame types vulnerable to an attack where one or more combinations of security features of the frame are present, and the operations comprises rejecting the frame if one of the one or more combinations is found.

14. The second device according to claim 10, wherein the indication of the security level includes one or more security bits indicative of the security level, and the operations further comprises extracting the security bits to determine the security level.

15. The second device according to claim 10, wherein the policy comprises a look up table correlating the frame type to at least one attribute.

16. The second device according to claim 10, wherein the frame further comprises a footer comprising one or more bits representing an error code.

17. The second device according to claim 10, wherein the header comprises a key identifier, a representation of a key corresponding to the key identifier, and an originator for determining an acceptability of the frame type.