《2020年亚马逊超远距新无线协议Amazon Sidewalk隐私和安全性白皮书 - 亚马逊(英文版)(13页).pdf》由会员分享,可在线阅读,更多相关《2020年亚马逊超远距新无线协议Amazon Sidewalk隐私和安全性白皮书 - 亚马逊(英文版)(13页).pdf(13页珍藏版)》请在三个皮匠报告上搜索。
1、Amazon Sidewalk Privacy and Security Whitepaper 1 Contents Introduction . 2 Overview . 3 Amazon Sidewalk Privacy. 3 Data Minimization . 4 Encryption . 5 Trusted Device Identities . 5 Amazon Sidewalk Security . 5 Device Registration and Deriving the Transmission ID (TX-ID) . 5 Packet from the Endpoin
2、t to the Application Server (Cloud) . 7 Packet from the Application Server (Cloud) to the Endpoint . 8 Conclusion . 10 Appendix . 11 Security only the intended destinations (the endpoint and application server) Amazon Sidewalk Privacy and Security Whitepaper 4 possess the keys required to access thi
3、s information. Sidewalks design also ensures that owners of Sidewalk gateways do not have access to the contents of the packet from endpoints (they do not own) that use their bandwidth. Similarly, endpoint owners do not have access to gateway information. The Sidewalk Network Server continuously “ro
4、lls”, or changes transmission IDs (TX-ID) and Sidewalk Gateway IDs every 15 minutes to prevent tracking devices and associating a device to a specific user. Data Minimization Sidewalk minimizes the use of metadata wherever possible. Sidewalk uses the metadata needed to route packets from (to) the en
5、dpoint to (from) the Sidewalk gateway, and then to (from) the Application Server. For example, when a packet is sent from the endpoint to the Application Server, the Sidewalk Network Server needs to know: Endpoint Sidewalk-ID to authenticate the Sidewalk-compatible device Endpoint Payload Size to en
6、sure the packet meets bandwidth limitations Transmission Time to apply the correct rolling transmission ID Gateway ID to select the appropriate gateway (GW) needed to relay the packet Application Server to route the packet from the endpoint to its respective cloud The Sidewalk Network Server (SNS) d
7、oes not know the contents of the packets or commands being sent over Sidewalk. In addition to the SNS, there are four other entities with access to certain types of data. Endpoint Owner: The owner of the endpoint can only view information that pertains to the normal operation of their device (i.e. w
8、hether their smart light is on or off). They are unable to see routing information, or what GW (if they do not own it) the smart light is receiving support from, as well as any information about that GW and GW owner. The GW information is encrypted behind the Sidewalk Network Layer and Flex Layer. G
9、ateway Owner: The GW owner is unable to see what endpoints (they do not own) are receiving support from their GW. They have no idea what types of endpoints are connected, times in which they are connected, or information about the owner of the endpoint. The endpoint information is encrypted behind t
10、he Sidewalk Application Layer. Application Server: The Application Server is unable to see any information pertaining to the GW owner, just the endpoint information. The GW-ID and information is encrypted behind the Sidewalk Network Layer and Flex Layer. Amazon Web Services (AWS): For Application Se
11、rvers hosted on AWS, AWS only sees the data the Application Server grants through Key Management Service (KMS). This data is generally used in AWS for storage, processing, and other services the Application Server utilizes. Amazon Sidewalk Privacy and Security Whitepaper 5 Encryption Packets travers
12、ing the Sidewalk network have three layers of encryption to ensure data is visible only to the intended party. This approach to encryption means that Amazon will not be able to interpret the contents of commands or messages sent through Sidewalk by third party services or endpoints (applications). S
13、ee additional encryption information below in the Amazon Sidewalk Security section. 1. The Sidewalk Application Layer enables secure and private communication between the endpoint and the Application Server. 2. The Sidewalk Network Layer protects the endpoints Sidewalk packet over the air. Plain-tex
14、t data in this layer is accessible only to the endpoint and the Sidewalk Network Server (SNS). 3. The Flex Layer, which is added by the Sidewalk Gateway (GW), provides the SNS with a trusted reference of message-received time and adds an additional layer of packet confidentiality. Plain- text data i
15、n this layer is accessible only to the GW and the SNS. Trusted Device Identities Unique identifying credentials make sure trusted devices can enter the Sidewalk network while preventing unauthorized devices from joining. The Sidewalk Network Server (SNS), Application Server, and each Sidewalk device
16、 (both gateways and endpoints) are provisioned with a unique set of Sidewalk credentials that are used during the Sidewalk device registration process to mutually authenticate each devices identity and to derive unique session keys between them. Encryption keys are derived periodically from their re
17、spective session keys using algorithmic encryption functions. Amazon Sidewalk Security Preserving customer privacy and security is foundational to the design of Amazon products and services, and Amazon Sidewalk provides multiple layers of privacy and security to secure data travelling on the network
18、 and to keep customers safe and in control. The Sidewalk security model is designed to authenticate the identity of all network participants, and to provide authenticity and confidentiality for all packets traversing the network. This helps to ensure that only the authorized, intended receivers have
19、 access to the corresponding packet information, and to ensure that users identity remains private while using the network. To illustrate the flow of data and encryption at each stage, we will begin with a tour through the system. This is demonstrated by an outdoor smart light (Sidewalk-ID A8905) wi
20、th a motion detection event. Device Registration and Deriving the Transmission-ID (TX-ID) When an endpoint starts the registation process on the Sidewalk Network, it must authenticate its identity and establish a unique session key with the Sidewalk Network Server (SNS) and Application Server. Upon
21、identity authentication, the SNS creates a random and unique index-ID (random value generated by the SNS when entering it into the lookup database), and a database (DB) record containing the following five elements: (1) index-ID, (2) unique session key, (3) transmission-ID (TX-ID) generation key, an
22、d (4) TX-ID (75757). Next, the SNS adds this record to its lookup DB of authenticated devices, and forwards the association index-ID/Sidewalk-ID match to the Application Server. From this point forward, the SNS cannot identify a user or Sidewalk-ID from an index entry or TX-ID (only the Amazon Sidew
23、alk Privacy and Security Whitepaper 6 Application Server can). The SNS and device must refresh the session key periodically, creating a new index-ID and DB record. Failure to do so will prevent the device from roaming on the network and require it to complete the registration process again. The SNS
24、makes it difficult for anyone, including Amazon, to piece together activity history over time, by changing the TX-ID every 15 minutes to a different unique identifier (see Figure 1). For example, the TX-ID is 75757 at t(0) or 7:00, and 43759 at t(1) or 7:15. For latency considerations, four unique c
25、odes are created at t(0), representing every 15 minutes for the next hour. Sidewalk limits the ability to work backwards through a trail of old IDs linked to the original device by continuously flushing the previous IDs after it has changed over two time periods. For example, at 7:31pm when the TX-I
26、D is now 87305, the t(0) TX-ID, 75757 is deleted. The SNS cannot resolve the source of the packet to a user/Sidewalk-ID. It stores the packet for one minute, and the packet routing information of the packet for one day. Once the packet reaches the Application Server, the TX-ID is matched to the real
27、 customer identifier and can only be seen by the Application Server, not the AWS host2. Figure 1: Breaking the Chain 2 Unless the Application Server grants access to AWS through KMS Amazon Sidewalk Privacy and Security Whitepaper 7 Packet from the Endpoint to the Application Server (Cloud) Next, wel
28、l walk through the smart light (A8905) sending a packet (motion detected) through Sidewalk to the Application Server. Figure 2: Endpoint PacketApplication Server Amazon Sidewalk Privacy and Security Whitepaper 8 The endpoint encrypts the first and second layer before transmitting the packet to Amazo
29、n Sidewalk. The first encryption layer encrypts the packet “BrandX smart light detects motion at 7:00 pm on 4/3/2020” using the Application Server Key; only the endpoint and Application Server have access to the endpoint-specific Application Server Key. This yields the Encrypted Application Payload.
30、 The second encryption layer encrypts the Encrypted Application Payload and other Sidewalk frame fields using the Amazon Sidewalk Network Server Key; only the endpoint and the Sidewalk Network Server have access to the Sidewalk Network Server Key. This yields the Encrypted Sidewalk Packet. At this p
31、oint, the endpoint transmits the Sidewalk packet over the air. The Sidewalk Network Server (SNS) can gather routing information for regular operations (i.e. to forward the packet to the Application Server, network health status, and network bandwidth caps). The third layer of encryption is performed
32、 by the Sidewalk gateway after it receives the Encrypted Sidewalk Packet and before it is transmitted to the SNS. Once the incoming packet is inspected, the Sidewalk gateway creates a Flex message with the Encrypted Sidewalk Packet and encrypts using the Gateway Network Server Key, yielding the Encr
33、ypted Flex Message. Only the Sidewalk gateway and the SNS have access to the Gateway Network Server Key. Once the SNS receives the Encrypted Flex Message, the decryption process begins. The decryption and inspection of the Encrypted Flex Message and the Encrypted Sidewalk Packet is performed by the
34、SNS in the same manner as the encryption process, but in reverse order. The SNS forwards the Encrypted Application Payload to the Application Server, which then decrypts it with its endpoint-specific Application Server Key. The plain-text message can only be seen by the Application Server. In this e
35、xample, the Application Server is hosted as a standalone AWS managed service. Access to data that is generated, stored, and flowing within AWS is governed by the Applications (endpoints) AWS key. The Application Server stores all of its persistent data (device identifiers, authentication material, c
36、ertificates, and encryption keys) encrypted in databases, and the master encryption key is stored in AWS Key Management Service (KMS). For Sidewalk (provisioning, key derivation, packet encryption/decryption) and AWS (rules-engine) libraries/services to access data, the Application server owner must
37、 grant access to Sidewalk/AWS by using KMS grant. If the Application server owner revokes access, Sidewalk and AWS no longer have access to Application resources (endpoint data) and the Application Server and endpoints can no longer operate on the Sidewalk Network. Please refer to AWS Shared Respons
38、ibility for more information on shared security for applications hosted on AWS.3 Packet from the Application Server (Cloud) to the Endpoint The encryption example above depicts any type of packet traveling from the endpoint to the Application Server. The Sidewalk Network Server stores only the routi
39、ng information from the last packet received, which is how the correct Sidewalk gateway-to-endpoint relationship is maintained for the packet flow we will discuss in Figure 3. In this example, a customer queries the Application Server to turn on their BrandX smart light. 3 Amazon Sidewalk Privacy an
40、d Security Whitepaper 9 Figure 3: Application Server Packet Endpoint Amazon Sidewalk Privacy and Security Whitepaper 10 When the customer uses their mobile app to turn on their light, the command is identified by the Sidewalk Device ID (or Sidewalk-ID), which is A8905. The Sidewalk-ID is established
41、 during the device manufacturing process, and can be the device serial number for certain devices. The encryption process is similar to the incoming packet described previously, but in reverse order with several nuances. In this example, the Application Server sends a packet destined for a Sidewalk
42、endpoint with the endpoints Sidewalk-ID as the destination (A8905). The Application Server does not know the transmission-ID (TX- ID) for a given endpoint, so the Sidewalk Network Server must first identify the TX-ID (43759) that is currently associated with the endpoint. This is done by performing
43、a look-up against a table that retains only the previous two TX-IDs. The Sidewalk Network Server then identifies the Gateway-ID (67492) that sent the most recent uplink packet associated with the device, and then sends the packet to that Gateway through the Sidewalk Network Server for delivery to th
44、e endpoint. This approach to encryption allows us to deliver information through the Sidewalk network while protecting the privacy of all the parties involved. Conclusion With connectivity support from the community, Amazon Sidewalk improves coverage, provides offline functionality, and enables troubleshooting to improve the smart home experience. By sharing a small portion of their home network bandwidth, neighbors give a littlebut get a lot in return. As a crowdsourced capability, security and priv