start	end	text
3060	8540	Firstly, thank you for giving a chance to talk here.
8540	11510	We are very grateful for this chance.
12040	14620	We will show the presentation titled
14620	22330	Realistic Trends in Vulnerability Based on Hacking into Vehicles from Tokyo.
24220	30460	OK, at first, please let us introduce ourselves briefly.
32080	34240	Who am I?
35720	37880	Do you know Denso?
38160	44180	They are one of the top automotive component suppliers in the world.
44380	46960	Do you know NRI?
47060	50520	Is it a very famous company?
51320	54820	Honestly speaking, I really don't know.
54820	63020	But they are famous, at least in Japan, on IT and IoT security.
64200	69180	NIDS is jointly founded by these two companies.
69300	70920	Yeah, so cool.
71540	78600	And I mentioned an important thing that our clients often ask us.
78600	88680	We never ever share the issues and vehicles information with Denso and NRI without your permission.
88680	94180	So please feel free to contact us.
99400	103480	NIDS activities on business.
103680	112380	We provide the cybersecurity assessment and consultation services for 6 OEMs and several suppliers.
113310	120720	On competition, we'd like to mention our activity on the Car Hacking Village.
120720	131650	We are a CTF and we got this position two years ago and fourth in last year.
132060	136900	So we believed to get third this year.
136900	144180	But unfortunately, we got accepted for this presentation.
144180	149200	So we are not ready now for that CTF.
149600	152960	Yeah, that is a bad thing.
156450	164810	On behalf of our company, I'd like to introduce fantastic four providing this presentation.
166390	167790	Ryosuke Uematsu.
167790	173950	He's known as a wireless enthusiast in Japan.
174550	177230	He loves LG so much.
177230	185290	In our company, he is known as living in radio anechoic chamber.
185650	192670	And we believe that he can see the radio waves over the air.
192670	199030	Shogo Nakao. He used to work for Functional Safety.
199230	203410	But now he is a binary otaku.
204250	210530	We've heard that his friend is only either pro.
211630	213810	Next, Ryoichi Teramura.
214430	219070	He leads our team and he is a cryptographer.
219070	224230	His favorite cryptography is 3D.
225650	230150	And Tatsuya Katsuhara. It's me.
230150	233810	I'm director of NDS.
235590	238410	Yeah, introduction. That's all.
243360	249760	These years, a number of car threats have been reported.
249760	256940	You may know the Jeep and recently BMW and Lexus issues are reported by Tencent.
257320	260820	Yeah, they are so cool.
261280	266960	The automotive industry has done a lot on cybersecurity.
267020	272420	The most famous one is WP-29.
273160	276160	It requires really a lot of things.
276160	293600	Software development lifecycle, security operations center, inclusion, detection and prevention system, product security incident response team, PSAT, and so on.
293600	299840	And don't forget ISO SAE-21434.
300840	308160	The important thing is that car developing process takes so long.
308680	321840	So there is a gap between the publication of research about certain vulnerability and actual release of countermeasure.
321840	329320	So I have defined car cybersecurity generation based on these gaps.
329500	338900	First, generation 0 is before Jeep. Almost no mitigation, no regulation.
339900	343880	Generation 1 is after Jeep.
343880	353160	Some ready-to-go countermeasures like gateway ECU are implemented.
353160	358220	But no electrical platform refurbishment.
359440	361200	Generation 2.
361520	373240	Our presentation focuses on this generation where new security countermeasures are implemented.
374600	376660	Generation 3.
377300	389200	This generation includes security features complied with WP-29 and ISO standard.
393740	395020	Okay.
395600	402320	So, yes, what we are going to talk about in this presentation.
402320	407780	First, we introduce our testing approaches.
408260	419340	Second, we introduce the trends of the vulnerabilities we found for second-generation vehicles and ECUs.
419340	427540	These results are based on more than 40 ECUs and 300 vulnerabilities.
427540	431380	Here are some of the examples.
431380	435680	And then we present effective mitigations.
437590	447150	Of course, we have already reported these vulnerabilities to car manufacturers and suppliers directly.
447150	454150	So it shouldn't be a threat in the actual car.
454170	456470	I think.
457470	469270	I believe that many car manufacturers and ECU suppliers are developing second-generation products just now.
469270	478210	So I hope the results of this analysis will help such a developer.
479130	484150	Okay, I'll turn it over to Teramura.
485150	488470	Okay, hello, nice to meet you.
488470	490630	My name is Yoshi Teramura.
491390	498250	And before getting to the main point, let's talk briefly about our testing methods and approaches.
500610	505190	We think there are two main categories of car testing methods.
505370	509310	The first one is a test for the vehicle itself.
509450	512330	Another is a test for each ECU.
512330	516730	So these tests are different in their purpose.
517550	520010	ECU test is just a unit test.
520010	525090	So it can test a detail but cannot see the entire vehicle.
525510	529790	But vehicle test is like an integration test.
530250	533810	It is difficult to check the detail.
533910	541270	But it's easy to check whether a vehicle can run or not during the test.
542270	546550	So we have experienced both tests.
546610	555490	And we think ECU test is more suitable for finding vulnerabilities than vehicle test.
555630	560630	So this presentation focuses on vulnerability.
560630	565570	So we have an analyzer result of our ECU test results.
570390	575510	First, we explain ECU test methods and approaches from the next page.
580940	584740	ECU test is that it can find vulnerabilities in the ECU.
586180	589100	This slide shows two graphs.
589160	592140	The left graph shows ECU stats.
592140	596640	And the right graph shows our test approaches.
598080	602000	The ECU consists of a lot of components.
602220	604760	It is shown in the left graph.
605000	607100	For example, hardware.
607180	609820	Of course, the interface drivers.
610080	611360	OS kernel.
611740	613100	And the bootstrap.
613260	614740	And the middleware.
614740	616500	And the open-source software.
616660	620420	And of course, applications that run on the OS.
621960	625460	Do you know where is the vulnerability?
626280	628540	Of course, the answer is easy.
628540	630700	The answer is everywhere.
631860	638180	There are vulnerabilities everywhere in the ECU stats.
639660	644240	And to find them, we use a lot of test methods.
647620	652400	The right graph shows our test methods and approaches.
652400	656750	And our test methods are divided into two categories.
657100	659200	One is interface test.
659200	662640	And another is software analysis.
663680	667320	Interface test is one of the black box tests.
669260	673760	Finding vulnerabilities through ECU's interface.
674180	680840	And software analysis is one of the white box or occasionally gray box tests.
680840	684060	Okay, let's take a look at each method.
688020	694400	First, I will introduce interface test and especially remote interface test.
694400	695900	That is Celera.
696540	700980	Do you know this box in this picture?
701840	704580	And this is an unread product.
704580	712860	And this unread product comes as a spoofed base station of LTE or 3G.
712860	717980	And we use it and check the connected services over the Celera network.
718820	724120	And by spoofing and monitoring the messages during connection and authentication sequence,
724460	727600	we can check the protocol stack of the Celera interface
727600	735220	and simulate some attacks like authentication bypass and micromodal attacks over the Celera network.
736380	740300	But there is one caution point.
740300	747580	In some countries, like Japan, the radio law prevents this type of test.
747840	753560	So you must check your country's law before remote interface testing.
755300	758680	Okay, let's go. Next, adjacent interfaces.
759660	768580	Adjacent interfaces are like Wi-Fi and Bluetooth, NFC, radio frequency, and more.
770300	774180	This test doesn't need a spoofing base station.
774280	779180	And we connect our laptop to the ECU via the Wi-Fi or Bluetooth
779180	784440	and send a spoofing message and monitor the responses.
787020	792600	Then we check the vulnerability in the protocol stack and authentication function.
793380	797520	We often use a scanner tool in this test.
797520	804000	And it can find authentication bypasses and some well-known vulnerabilities.
805220	808940	Next, the local interfaces.
809060	816060	We show the local interfaces like a USB or CAN.
816500	818780	Everyone likes CAN.
818780	823680	And inter-ethernet and more.
823680	832360	And in this test, we connect the laptop to the ECU directly via cable or harnesses.
832480	835680	And we often check the security access for UDS and...
838860	841700	occasionally, are internet services remaining?
842260	848140	Okay, and we use a tool like a hotting tool and a scanner tool for this test.
851200	852900	Okay, next one.
853300	855980	Okay, next one is physical interfaces.
857260	869100	Physical interfaces target JTAG, SPI, UART, and more installed in the chip.
869100	878240	The purpose of this test is to check whether we can extract firmware or overwrite the firmware.
881040	884760	The microcontroller or external flash on the chip.
886560	891270	Okay, and in this test, very important skill is soldering.
891540	893800	So our staff is very skillful.
896160	897760	Okay, next.
898220	899880	Dynamic software analysis.
901640	909000	If we can extract the firmware from the ECU, we try the software analysis, static and dynamic.
909700	911960	The dynamic software analysis.
912000	925760	We log in the application on the actual or virtual ECU via SSH and UART and more.
926420	934040	And when we can connect to the ECU, check the internal of them.
934440	937480	Once logged in, we can check a lot of things.
937480	946340	Scanning processes, log files, software version, setting files, credential files, and many data.
949580	954440	And of course, if we can get the firmware, we'll try the static software analysis.
955240	965000	We need a firmware as an assembler or sometimes pre-code using it too, such as AIDA Pro or GDRA.
967440	971800	And we can use it and search the vulnerability.
973700	980480	If the firmware includes an operational system such as Linux, we can run it on a virtual machine.
980840	988080	And if the firmware includes a file system, we can mount the file system and check the files in it.
988920	995420	So we think the firmware is a good alternative of a source code and a debug console.
996780	999140	The software tells us many things.
999220	1001600	Many, many things, a lot of things.
1002260	1005060	There are known vulnerabilities.
1005720	1011240	And what is open source software and Office 365 product versions?
1011540	1016160	And is there a debug port? And is there remaining services?
1016160	1021520	What is configuration? Where is the hard-coded credential?
1022360	1025160	Software analysis tells many things.
1027200	1031100	Okay, this is a wrap-up, the test result.
1031440	1034580	But this time we skip it.
1035840	1041520	Okay, the last. Here is our matrix to the risk score of the vulnerabilities.
1041920	1045880	The risk score is determined based on two factors.
1046160	1049620	One is damage impact and one is attack feasibility.
1049700	1055640	Damage impact and attack feasibility are evaluated from the view of vehicles.
1055920	1058880	From the vehicles, it's an important point.
1060400	1066060	From the view of vehicle users, vehicle users' safety.
1067160	1070460	So it's from not only ECU.
1071320	1080620	This means that the risk score related to the vulnerabilities of internal network tends to be decreasing.
1081700	1090080	Okay, from the next page, we will show our analysis of the vulnerabilities and their risk score from Kyosuke Uematsu.
1092420	1099380	Okay, I'm Kyosuke Uematsu. I'm talking about vulnerability trends in vehicles.
1101180	1106360	First, let me discuss the background data for this analysis.
1106780	1113380	Our results are derived from over 300 vulnerabilities we have found in the past.
1114000	1120780	These vulnerabilities are derived from more than 40 issues provided by more than 10 companies.
1121060	1126620	In this analysis, we will talk about four categories of issues.
1126620	1131080	First, the IBEX category. IBEX is in vehicle infotainment.
1131080	1138900	It has many features, mainly navigation system, play music, and calling with your smartphone, and so on.
1138900	1143560	It has an adjacent interface such as wireless LAN and Bluetooth.
1144360	1146680	Second, the TCU category.
1146880	1154500	TCU is telematics control unit. It has several interfaces such as 4G, 3G, and 2G.
1154500	1159520	Some of them have Wi-Fi interface for access point.
1160180	1162260	Third, the Gateway category.
1162260	1170800	It has mostly CAN and Ethernet connection, but often OBD2 is connected here.
1171160	1180660	The Gateway has features to separate the communication between the IBEX or TCU and the control system issues such as engine or steering issue.
1180660	1184020	And then, the other category.
1184020	1188900	It includes ADAS, smart key, charging, and BTX ECUs.
1190620	1196940	OK, first, let me talk about where most of the vulnerabilities are found.
1197380	1202940	The structure of an issue consists of hardware layer and software layer.
1202940	1212240	Here, the software layer has OS, OSS, off-the-shelf products including interface module, and application.
1212780	1222300	For this structure, about 70% of vulnerabilities are found in OS, OSS, and off-the-shelf products.
1222500	1230280	For example, these 70% vulnerabilities have a lack of management for OSS version.
1230280	1238580	Using an OSS version reported vulnerability in the vulnerability database like a CVE.
1238900	1244200	Using an inappropriate off-the-shelf products, and so on.
1245400	1251860	OS, OSS, and off-the-shelf products are developed by a third party.
1251860	1259480	And in many cases, they have already provided the patches for their vulnerabilities we found.
1259480	1265820	Pay attention to OS, OSS, and off-the-shelf products is very useful mitigation.
1267420	1271720	OK, next, focus on the high-risk vulnerabilities.
1272860	1282840	As a result, the 30% vulnerabilities are in application, and 70% in OS, OSS, and off-the-shelf.
1282840	1288500	So, almost high-risk vulnerabilities are in software, not hardware.
1289480	1297520	It means that hardware vulnerabilities hardly affect the threat scenario of vehicle user safety.
1298120	1305560	Thinking of defense in depth, of course, hardware security is non-negligible.
1305840	1309860	But, software security may be more important than it.
1311920	1316360	OK, next, focus on software vulnerabilities.
1316360	1322680	I've categorized software vulnerabilities into nine major categories.
1323540	1336360	Insecure OS, OSS settings, insecure authentication, information leakage, use of insecure or outdated components, insecure application layer communication, and so on.
1336400	1343340	The most often detected vulnerabilities are insecure OS and OSS settings.
1343340	1349460	As we said, this is a trend in second-gen cars. We will dig deeper.
1351440	1356180	We filter vulnerabilities more than medium-risk scores.
1356540	1362640	It means that we focus on the vulnerabilities that may cause vehicle user safety.
1363500	1371200	Through this filter, the insecure OS, OSS settings, lags down to third place.
1371200	1378440	First place is insecure authentication, and second place is lack of secure update mechanism.
1379660	1386160	These are two top vulnerabilities that could be a threat to the vehicle user safety.
1386540	1393320	The example of insecure authentication is storing key or password in parentheses.
1393320	1402700	So it may be good mitigation to keep credentials in secure elements such as trust zone, TPM, and HSM.
1403640	1411300	The example of lack of secure update mechanism is improper implementation of signature verification.
1411500	1416460	Thus, it is important to implement the signature verification strictly.
1418400	1422220	Next, we focus the issue category.
1422220	1427700	This slide message may be intuitive to you.
1428060	1438360	That is more complex ECU that have various functions, such as IBOA, has a greater number of vulnerabilities than others.
1438700	1444660	The left graph shows the average number of vulnerabilities for each ECU.
1445040	1451360	On average, we find 10.9 vulnerabilities for each IBOA.
1452360	1458720	5.6 for each TCU, and 3.5 for each gateway.
1459440	1466440	The right graph shows the proportion of vulnerabilities for each RISC.
1467360	1474640	It is also the IBOA that is most likely to detect high-risk vulnerabilities.
1474940	1477620	The reason for that is simple.
1477620	1483780	It has a lot of applications, OS, OSS, and a lot of interfaces.
1486500	1489980	OK, next, focus the testing method.
1490660	1494720	First, let me talk about the remote interface test.
1495580	1507340	This graph shows the proportion of vulnerabilities we found in remote interface test, including Bluetooth, wireless LAN, server, and so on.
1507620	1512720	The interface that found the most vulnerabilities is Bluetooth.
1513780	1519000	Especially, Bluetooth authentication bypass vulnerabilities were most detected.
1519920	1525940	We think this is because Bluetooth security countermeasures are not yet well known.
1526880	1536860	On the other hand, wireless LAN and server don't have as many vulnerabilities, but some of them are serious problems.
1537620	1542740	OK, next, let me introduce the example of Bluetooth and server.
1544720	1550700	First, talk about the example of vulnerabilities in Bluetooth.
1551440	1556880	Bluetooth has some vulnerabilities that can bypass authentication.
1557220	1559500	First, using PIN mode.
1559500	1562520	Bluetooth has two authentication modes.
1562520	1567900	One of them is PIN mode, and it is well known to be vulnerable.
1568620	1575340	Some of issues there are PINs were 0, 0, 0, 0. It seems vulnerable.
1575940	1581540	Second, the BDLS spoofing, that is called CAS blues.
1581820	1586780	And third, the no-input output of IO capability spoofing.
1587820	1596980	These vulnerabilities are that an attacker can connect to the vehicle Bluetooth interface without user operations,
1596980	1601640	and then perform any operation over Bluetooth interfaces.
1601660	1607120	If a debugged serial service would remain over the Bluetooth interface,
1607120	1614900	an attacker can connect to the debugged serial service and execute any command by exploiting these vulnerabilities.
1615900	1626060	At least, stop using PIN mode and take care of CAS blues and no-input output devices.
1627260	1630990	Next, let me talk about the server vulnerabilities.
1632200	1637960	Server vulnerabilities are not so many, but sometimes found.
1638200	1642210	We introduce one example we have found.
1642930	1649150	We try the method of relative fuzz that can bypass server authentication.
1649610	1656630	Of course, a lot of issues don't be exploited, but one issue could be exploited.
1656770	1662170	When I found it, I really couldn't believe it.
1662230	1671050	This is really bad because it allows the attacker to spoof the base station and to attack the vehicle remotely.
1671050	1677380	In addition, the information on the server communication leaks to the attacker.
1678750	1683890	The cause of this vulnerability is in the server stack provided by JitBender.
1683890	1690930	Therefore, this mitigation is to get the latest software from JitBender and apply it.
1693250	1698390	OK, next, talk about trends for the interface in the vehicle.
1698890	1702110	Take a look at the graph on the left.
1702410	1707650	Most of them are CAN. In-vehicle Ethernet is also important recently.
1708630	1717450	About 80% of the vulnerabilities we found are related to in-vehicle networks, including CAN and Ethernet.
1717750	1724590	So, let's check what type of high-risk vulnerabilities of the in-vehicle networks.
1724710	1728430	As shown in the graph on the right,
1728430	1735310	many UDS-related vulnerabilities are found in the in-vehicle networks.
1735410	1740670	In the next page, let me show you some of the UDS-related vulnerabilities.
1743190	1748410	Broken security access protection is a typical problem.
1748730	1756230	Recently, message authentication is started to be implemented to secure messages of in-vehicle networks.
1756230	1759470	For example, CAN and Ethernet.
1759470	1763390	This is a pretty powerful countermeasure.
1764170	1774370	By contrast, for UDS, security access is still a primary countermeasure for security.
1774370	1779750	Some of the UDS vulnerabilities we found are as follows.
1779750	1784190	1. Lack of entropy in seed generation.
1784670	1789630	2. Insufficient initializes for random number generator.
1789630	1796070	3. Extracting sensitive information using UDS service, such as read by ID.
1797290	1806730	In addition, there is a problem that the private key is hard-coded and can be identified by software analysis.
1806730	1812950	This will be explained later in software analysis section with example.
1814470	1827730	Although UDS connection to be an attack surface of ECU, it is becoming more and more difficult to attack UDS due to the effect of domain separation by gateway.
1830810	1838190	Next, let me talk about trends in vulnerability of physical debug interfaces on the ECU.
1838870	1847330	This graph shows the proportion of the ECU where physical debug interfaces remain unlocked.
1847650	1853810	There are three types of vulnerabilities for the physical debug interfaces on ECU.
1853850	1859210	1. The debugging access to the CPU via JTAG interface is available.
1859650	1865610	2. The shared access to the CPU via UART interface is available.
1865610	1873970	3. It is extraction of firmware from external RAM on the ECU, such as eMMC.
1874610	1884750	As you can see from the left graph, 41% of ECUs can be accessed via JTAG interface.
1884750	1893350	The next graph shows that 32% of ECUs can be accessed via UART.
1893350	1903170	As you can see from the right graph, 44% of ECUs can be extracted the firmware from eMMC or others.
1904330	1910610	The main reason is that the debugging interfaces are not locked in most ECUs.
1910930	1917530	Even if you have locked the debugging interfaces, they are not properly locked or disabled.
1919610	1930390	For example, JTAG is locked, but password is default value. It doesn't mean it's locked.
1930390	1933930	Thus, of course, you must fix it.
1935410	1938910	OK, next presenter is Shogunakao.
1942900	1947260	OK, I'm Shogunakao. Hello, I'm Shogunakao.
1947260	1958700	Hereafter, we talk about the trend comparing interface testing and software analysis, and also talk about software analysis with examples.
1958880	1970320	We have been focusing on interface testing. However, there is a limit to the amount of vulnerability we found by interface testing.
1971320	1981220	For example, though we capture and analyze the communication data, we can check the security measures on communication channel.
1981860	1989480	It is rare that we can find vulnerabilities in the software related to the communication.
1990280	1995760	So we analyze binary files to find vulnerability in the software.
1996980	2008620	In fact, as shown in the left graph, we have found twice as many vulnerabilities through the software analysis as through the interface testing.
2009160	2019040	In addition, high-risk vulnerabilities tend to be found by the software analysis, as you can see from the right graph.
2019040	2032000	The reason for this is that the vulnerabilities found by the interface testing, like auto-scan, seem to be already fixed.
2032700	2038640	Of course, the high-risk vulnerabilities also seem to be already fixed.
2038640	2049740	Therefore, I think it would be significant to analyze software and binary files to find vulnerabilities in the car development.
2050580	2057030	But we need to obtain binary files in order to analyze the software.
2058120	2067060	For this reason, I think a good relationship between the car manufacturers, suppliers, and security vendors is essential.
2068060	2075400	In the following slide, we will explain some specific examples on software analysis.
2078580	2088460	In software analysis, we identify the code of the target process from the extracted binary files.
2088460	2099960	Then, we can understand the architecture of software and relate the data flow and functions of the process, as shown in this figure.
2100620	2110580	After that, we investigate and analyze the data flow and functions from the identified code more deeply.
2110900	2117300	This is how we gather detailed information about the target ECU.
2118460	2126850	Of course, we also identify and analyze the security functions by reading the binary code.
2127500	2141480	For example, we know that the ECU has containers, terrorist communication, signature verification, and cryptographic functions.
2141480	2149460	Then, we relate the code more deeply. We find a lot of vulnerabilities in this work.
2150300	2159320	Next, I'll explain examples of software analysis and vulnerabilities we have found.
2162120	2167040	The first example is analysis of an IBI code.
2167040	2174220	First step, we identified the process of encrypting the seed with AES.
2174900	2185240	Second step, we disassembled the target code in AIDA Pro and read it to find the AES key.
2186180	2189400	Let's read the assembly code.
2190420	2195400	We followed the core instruction as shown in the figure.
2195400	2201670	Then, we can saw that it refers to the data area in the function.
2202880	2210530	We noticed that the key for AES is in the area as we proceeded with the analysis.
2211740	2221750	When we looked for other functions that refer this data area, we could see that they initialize the same area.
2221750	2229770	As a result of analysis, we could find the information about the AES key, maybe, I think.
2230090	2236020	If this is a real AES key, we may be able to hack the IBI.
2238370	2244990	To prevent the leakage of the key, you can store it in the HSM.
2250060	2255440	The second one is about gateway firmware.
2256000	2261140	This is the same approach as the before slide.
2261140	2267260	Fortunately, we are able to decompile the code in GitHub.
2267940	2277480	This is because we identified the security access handlers and found the private key information in them rapidly.
2278200	2289800	In this analysis, we also identified the security access algorithm, so we were able to bypass the security access.
2291840	2297720	Binary files tell you a lot of information about the ECU and the vehicle.
2298340	2305720	It tells you how you can hack into the vehicle or ECU and how you can extract the sensitive data.
2307120	2312140	These are some of the vulnerabilities we found.
2312640	2332100	For example, you can see disabling TLS certificate validation, improper signature validation, and buffer overflows and directory traversal.
2332100	2338240	These lead to severe or high impact for the vehicle, I think.
2341460	2353120	After checking the trend of vulnerabilities, someone may ask us whether the second-generation cars face cybersecurity threats.
2353880	2359320	We will say it's secure in most cases.
2359320	2372260	It's difficult to realize a threat scenario for the vehicle in terms of vehicle architecture on both security features and so on.
2373020	2377320	In rare cases, they are unsecured ones.
2377700	2384260	But we've reported the vulnerability we found, so it must be already fixed.
2388990	2395590	We show five solutions against such vulnerability here.
2395950	2404310	85% of high and medium risk vulnerabilities can be mitigated by these solutions.
2404370	2409490	So, I sincerely recommend to introduce the solutions.
2410190	2417570	First of all, store credential and private keys in protected area.
2417570	2426470	For example, trust zone and TPM, HSM, or something like that.
2426470	2435730	Second, make sure that the signature verification is done correctly.
2436290	2440650	I'm not just talking about the verification algorithm.
2440650	2449930	There are some vulnerabilities that signature verification is bypassed due to verification timing issues.
2450510	2459130	Third, use appropriate random number generator and cryptosystem.
2459990	2469810	Fourth, on OS, OSS, and off-the-shelf, pay attention to the following three things.
2469810	2475210	The first one is use OSS properly.
2476010	2486910	For example, we often see unproperly settings in TLS connection using OpenSSL, CURL, and so on.
2487250	2495310	The second one is software version control and managing software composition.
2496310	2501510	The third one, secure OS and OSS configuration.
2502830	2512570	There are a wide range of settings, but most of them are firewall permissions and hardening settings for the OS.
2514050	2519610	Fifth, log the physical debug port on the hardware properly.
2520610	2525570	Finally, we will say it again.
2525570	2534890	Just by introducing these solutions, you can mitigate 85% of the high and medium risk.
2535170	2540190	We strongly recommend that you introduce these solutions.
2542520	2545900	And we conclude our presentation.
2545900	2548360	This is our conclusion.
2548360	2552400	We answer for frequently questions.
2552660	2554140	That's all. Thanks.
