0
1
00:00:00,750 --> 00:00:04,630
Before starting to explain all the network architectures available in LoRaWAN.
1

2
00:00:04,710 --> 00:00:09,720
I want to show you clearly in this figure where the LoRaWAN protocol stands.
2

3
00:00:10,440 --> 00:00:17,070
We explain in a previous videao that the LoRaWAN protocol is made of end devices, gateways, network and
3

4
00:00:17,070 --> 00:00:18,360
application server.
4

5
00:00:18,600 --> 00:00:25,800
Then most of the time, an Iot platform or other services are connected to the LoRaWAN server so they can
5

6
00:00:25,800 --> 00:00:27,630
import the data to process.
6

7
00:00:28,200 --> 00:00:34,470
But when we see this overall infrastructure, one could say, Hey, the application server is here to
7

8
00:00:34,470 --> 00:00:35,460
decrypt the data.
8

9
00:00:35,820 --> 00:00:40,620
So the data sent outside of the application server are not encrypted anymore.
9

10
00:00:41,370 --> 00:00:43,890
The answer is yes and no.
10

11
00:00:44,610 --> 00:00:48,930
Yes, because the data are not encrypted by the application session key anymore.
11

12
00:00:49,080 --> 00:00:54,660
So from that point data are not encrypted by the LoRaWAN protocol anymore.
12

13
00:00:55,020 --> 00:01:00,900
But on the other hand, we will obviously choose a secure protocol to send them to the Iot platform.
13

14
00:01:00,900 --> 00:01:07,410
So no, the data won't be sent in plaintext and the transmission to the IoT platform won't be unsecure.
14

15
00:01:08,160 --> 00:01:08,820
Okay.
15

16
00:01:08,910 --> 00:01:14,130
But the LoRaWAN protocol is supposed to support what we call end to end security.
16

17
00:01:14,580 --> 00:01:21,240
End to end security is the network capability to encrypt the data on the end-devices side and to decrypt
17

18
00:01:21,240 --> 00:01:22,920
it on the user side.
18

19
00:01:22,950 --> 00:01:29,650
So in our case, the LoRaWAN decryption should be on the IoT platform itself .With end to end security,
19

20
00:01:29,670 --> 00:01:33,990
there is no way to have malicious intrusions between the device and the user.
20

21
00:01:34,760 --> 00:01:35,400
Okay.
21

22
00:01:35,400 --> 00:01:41,940
But here it's not the case because the application server decrypts data and then they are encrypted
22

23
00:01:41,940 --> 00:01:43,620
again with another protocol.
23

24
00:01:44,490 --> 00:01:49,830
If your provider proposed such an infrastructure, that means that it can read your data.
24

25
00:01:50,280 --> 00:01:56,700
And if you want to be sure that nobody can read them, even the LoRaWAN provider, then the application server
25

26
00:01:56,700 --> 00:01:59,220
should handle the decryption on the user side.
26

27
00:01:59,250 --> 00:02:01,380
So here on the figure.
27

28
00:02:01,860 --> 00:02:07,710
So when you choose a LoRaWAN provider, if you want end to end security, that's something you have
28

29
00:02:07,710 --> 00:02:08,820
to care about.
29

30
00:02:08,940 --> 00:02:13,590
So anyway, for this lecture, we don't really care where is the application server.
30

31
00:02:13,620 --> 00:02:18,390
We'll just consider the application server has the capability to decrypt the user data.
31

32
00:02:18,480 --> 00:02:22,320
And that's exactly what the LoRa Alliance says about the application server.
32

33
00:02:22,350 --> 00:02:23,340
Nothing more.
33

34
00:02:23,740 --> 00:02:27,120
And wherever it is, it won't challenge our explanation.