White Rabbit in Mobile: Effect of Unsecured Clock Sourcein Smartphones

Shinjo ParkTU Berlin & Telekom

Innovation Laboratoriespshinjo@sec.t-labs.tu-

berlin.de

Altaf ShaikTU Berlin & Telekom

Innovation Laboratoriesaltaf329@sec.t-labs.tu-

berlin.de

Ravishankar BorgaonkarOxford University

ravi.borgaonkar@ac.ox.ac.uk

Jean-Pierre SeifertTU Berlin & Telekom

Innovation Laboratoriesjpseifert@sec.t-labs.tu-

berlin.de

ABSTRACTWith its high penetration rate and relatively good clock ac-curacy, smartphones are replacing watches in several marketsegments. Modern smartphones have more than one clocksource to complement each other: NITZ (Network Identityand Time Zone), NTP (Network Time Protocol), and GNSS(Global Navigation Satellite System) including GPS. NITZinformation is delivered by the cellular core network, indi-cating the network name and clock information. NTP pro-vides a facility to synchronize the clock with a time server.Among these clock sources, only NITZ and NTP are up-dated without user interaction, as location services requiremanual activation.

In this paper, we analyze security aspects of these clocksources and their impact on security features of modernsmartphones. In particular, we investigate NITZ and NTPprocedures over cellular networks (2G, 3G and 4G) and Wi-Fi communication respectively. Furthermore, we analyzeseveral European, Asian, and American cellular networksfrom NITZ perspective. We identify three classes of vulner-abilities: specification issues in a cellular protocol, configu-rational issues in cellular network deployments, and imple-mentation issues in different mobile OS’s. We demonstratehow an attacker with low cost setup can spoof NITZ andNTP messages to cause Denial of Service attacks. Finally,we propose methods for securely synchronizing the clock onsmartphones.

Keywordsbaseband; NITZ; NTP; timekeeping; cellular network; clock

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from permissions@acm.org.

SPSM’16, October 24 2016, Vienna, Austriac© 2016 ACM. ISBN 978-1-4503-4564-4/16/10. . . $15.00

DOI: http://dx.doi.org/10.1145/2994459.2994465

1. INTRODUCTIONThe convergence towards smartphones, and the new mar-

ket opened by wearables integrated several devices intothem, including wrist watches. According to CNET, thepopularity of smart watches negatively affected the sales oftraditional wrist watches [43]. Like wrist watches, they aredesigned to be carried every day, providing accurate time in-formation. While watches require manual adjustment whenthe battery has been changed or when there is a changeregarding DST (Daylight Saving Time)1, smartphones au-tomatically retrieve current time information from multiplesources and propagate it to connected wearables like smartwatches. Moreover, a clock mismatch or a DST adjustmentis automatically corrected in the smartphone by periodicclock synchronizations. In contrast, watches require manualadjustment when the same happens.

Today’s smartphones obtain clock2 information from mul-tiple sources and interfaces. Smartphones without Internetconnectivity can use cellular network provided NITZ (Net-work Identity and Time Zone) information, and Internet-capable smartphones can synchronize clock information overthe Internet using protocols like NTP (Network Time Pro-tocol). Other integrated devices like GNSS (Global Navi-gation Satellite System, including GPS and GLONASS) arealso capable of providing clock information. It is up to thesmartphone manufacturers and OS (Operating System) de-velopers’ policy to utilize and assign priorities to each clocksource. Besides smartphones, M2M (Machine to Machine)and IoT (Internet of Things) devices also rely on these clocksources [22].

When the “Automatic clock update” is enabled in mobileOS, it will fetch clock information from multiple sources.The way this information is fetched depends on OS andmanufacturer policies, and varies among smartphones. Fur-thermore, it is also unclear how smartphones manage thesedifferent clock sources. NITZ is an optional message carry-ing network name and clock information on 2G, 3G and 4G

1Although a few higher-end watches are capable of auto-matic clock synchronization based on external signals, theyare not widely used in the market.2In this paper, we use the term clock referring both time anddate. Time is used when usage of time is explicitly required.

13

cellular network. NTP utilizes the Internet connection tosynchronize with a time server, and most mobile OS includ-ing Android and iOS are capable of clock synchronization viaNTP. Unlike NITZ and NTP, GNSS services must be man-ually turned on by the user to retrieve clock information.Therefore we only discuss NITZ and NTP in this paper, asthey are updated without explicitly asking the user.

In this paper, we show that it is possible to spoof clock in-formation on modern smartphones by any third party, or anattacker with a rogue base station and Wi-Fi access point.We highlight that due to the lack of standard timekeep-ing methods among vendors and OS developers, unintendedconsequences arise on mobile OS and apps. We also discussinteresting problems with smartphones using 32-bit and 64-bit that lead to OS crashes.

To this end we make the following contributions:

• We systematically analyze security aspects providedto NITZ feature in the 3GPP (Third Generation Part-nership Project) specifications of 2G, 3G, and 4G net-works. The analysis indicates a lack of authenticationand integrity protection in 2G networks.

• We built an experimental real network to demonstrateattacker’s capabilities to spoof NITZ information andinvestigate their impact against both mobile and base-band OS. Furthermore, we discover NITZ configura-tion issues in several deployed cellular networks. Wepresent a class of Denial of Service attacks by exploit-ing weaknesses in a 3GPP specification, device andcellular network configurations, and implementationissues in few baseband operating systems.

• We propose countermeasures for Denial of Service at-tacks and present best practices for mobile OS and appdevelopers to maintain clock accurately.

2. RELATED WORKWe divide related work into three categories: rogue base

station, NTP attack, and timekeeping on smartphones.Rogue base station attack. A fake base station can be

used to passively attack nearby mobile users. Due to spec-ification and implementation flaws, numerous private infor-mation leakage and malicious information injection attackswere proposed. An example of an information leakage is thelocation leak, which Kune et al. [34] and Shaik et al. [51]discovered on 2G and 4G network respectively.

Message injection attacks using fake base stations havebeen proposed in several works. Mulliner et al. [42] pre-sented SMS injection attacks, which resulted in a systemcrash in some cases. Weinmann [55] showed GSM controlplane message injection attacks, causing various impacts.Alecu [13] proposed an SMS-based attack to exploit SIMcard applications. Work of Shaik et al. [51] also containsmessage injection using a fake LTE base station. Theymainly use messages related to location leaks. To the bestof our knowledge, there are no studies evaluating risks as-sociated with clock spoofing via a fake base station in theliterature.

NTP attack. Because NTP lacks authentication andintegrity protection by default, and some NTP commandscould be used maliciously, both attacking NTP itself andusing NTP as an attack vector are proposed. Being anUDP/IP based protocol, any generic attack like spoofing

and redirecting on UDP and IP in addition to NTP-specificattacks can be performed.

There are a number of reported NTP server vulnerabilitieswhich could be used to affect NTP availability and time ac-curacy, including one from Rottger [49]. Malhotra et al. [35]presented several attacks on NTP. Attacks presented in theirwork are targeting both the NTP server and the transmis-sion channel to the client. Time-shifting attacks can alterany device that solely relies on NTP as a clock source. Weare not focusing on the NTP attack itself. Instead, we eval-uate how NTP and other clock sources are used in smart-phones and how spoofing one or more of them affects thesystem behavior.

Klein [33] showed the impact of attacking clock sourceson multiple platforms, including Android and applicationson it. Czyz et al. [23] analyzed NTP amplification attacks,an attack vector utilizing NTP. CloudFlare and other onlinegames were among the victim of this attack. Goodin [25]found this attack can cause DoS ranging up to 100Gbps.CloudFlare published details of how 400Gbps DDoS attacktowards their infrastructure was possible via NTP amplifi-cation [46].

Furthermore, NTP servers could be configured to fetchclock information from either another NTP server or high-precision clocks like GPS, radio and an atomic clock. NTPservers fetching clock information directly from precise clocksources is called Stratum 1 server, which takes a higher levelin the NTP server hierarchy and is used as a clock sourceof lower stratum servers. Zheng et al. [57] proposed an at-tack on radio clock signals used by some active Stratum 1servers. Compared to this work, our work directly targetssmartphones which receive time information from a cellularnetwork or an NTP server.

Timekeeping on smartphones. Several crashes andbugs were discovered related to internal time keeping of mo-bile OS. Straley found the regression on Apple iOS devices,when the device date is set to January 1970 [53]. Kelleyand Harrigan reproduced the same bug using NTP via Wi-Fi [32], using DNS spoofing on Apple’s NTP server. Appleacknowledged the problem and fixed it in iOS 9.3 and 9.3.1update [17].

3. BACKGROUNDIn this section, we briefly describe different types of clock

sources used by OS’s in smartphones. Among those sources,we only cover NITZ and NTP in detail. Further, we discusshow each OS obtains and synchronizes the accurate time onsmartphones.

3.1 Timekeeping in SmartphonesSmartphones are running two different operating systems:

one on the application processor and the other on the base-band processor. Although they are interconnected via acommunication stack on mobile OS (e.g. Android RadioInterface Layer), they maintain separate clocks.

The mobile OS clock could be set either by using infor-mation received from the baseband, or (Internet) data con-nection using NTP. This clock is used by all applicationsrunning on the OS. Due to the lack of standard methods, itis up to the OS and device manufacturers to select any ofthe available clock sources.

The baseband OS clock is usually set by the cellular net-work using NITZ information. This clock is also supplied to

14

mobile OS; however, it can decide whether or not to use thisclock. Normally the baseband uses this clock as a timestampfor the diagnostic messages and is invisible to users.

Most OS’s are keeping their clock as monotonically in-creasing value since a fixed epoch (e.g. 1st January 1970 onAndroid and iOS), and using a fixed sized variable to repre-sent the clock value. (time_t on Android and iOS) Windowshas different epoch and clock storage methods [37, 39].

3.2 NITZ3GPP specifications define signaling messages for carry-

ing NITZ information, called MM Information and GMMInformation for both 2G and 3G [9] and EMM Informationfor 4G [11]. NITZ consists of time, time zone, date, andoperator name. Time information in NITZ should be accu-rate in minute level, and the message itself has a minimumprecision of one second, according to [9].

3.3 NTPNTP [41] requires a time server to supply an accurate

clock source, and communicates with the smartphone us-ing UDP/IP. Information acquired over NTP contains dateand time. Smartphones may use either public NTP poolservers [3], or OS or device vendors can operate their ownNTP server.

4. SPOOFING ATTACKS VIA NITZ ANDNTP

In this section, we describe the threat model and attacksagainst NITZ and NTP methods. Further, we conduct prac-tical experiments to investigate configurational issues in sev-eral cellular networks. Finally, we present spoofing attacksvia a rogue base station and Wi-Fi access point.

4.1 Threat ModelThe attacker is capable of operating a rogue 2G, 3G or

4G base station. To achieve this, he or she has access tothe radio hardware and related software to impersonate theuser’s serving cellular operator network. Further capabili-ties include the knowledge of 3GPP and NTP specifications.Additionally, attacker can also operate rogue Wi-Fi accesspoint allowing open access to the mobile devices nearby.

4.2 Experimental SetupFigure 1 shows our experimental setup. For NITZ, our

hardware consists of a host PC and a USRP B210 device,connected via USB 3.0. The host PC runs all the softwarerequired to operate a cellular network, available from vari-ous open source projects: OpenBTS [47] for 2G, OpenBTS-UMTS [48] for 3G, and OpenLTE [56] for 4G. We modifiedthese software stacks to operate as rogue base stations. Wehave selected popular smartphones from various basebandand OS manufacturers for our test purposes.

Additionally, we built a custom tool by reverse engineeringa baseband to capture 2G, 3G, and 4G network messagesfrom the test phones. In particular, we analyzed controlplane messages and baseband timestamps.

For NTP, we operate a Wi-Fi access point based on Open-WRT, and a custom NTP server based on busybox-ntpd [21].We configured access point to connect every smartphonenearby.

Figure 1: Our experimental setup, showing theUSRP (left), a Wi-Fi access point (center, dottedsquare), and our test phones.

Ethical concerns. 2G, 3G and 4G network experimentsare performed inside a faraday cage to obey to legal regula-tions and avoid interference with other phones. The nameof the Wi-Fi network is clearly indicated as an experimentalnetwork. Further, we responsibly informed all the affectedmobile OS and smartphone vendors and our reports wereacknowledged by them.

4.3 Attack BackgroundWe now discuss the security procedure defined for NITZ

features in 3GPP and evaluate how cellular network opera-tors deploy these features in practice. We also analyze themanagement of NITZ and NTP clock sources, and their ef-fect on the mobile OS. We will later utilize these aspects todesign our attacks.

4.3.1 Security Issues in 3GPP SpecificationsAlthough the content of NITZ messages is similar in all

the network generations, their security requirements are dif-ferent and are discussed below. These security requirementmeans the way NITZ messages are transferred between thebase station and the mobile device.

2G

The 2G specification [9, 8] defines ciphering as an optionalfeature, but lacks mandatory mutual authentication and in-tegrity protection on signaling messages including NITZ.Thus, an attacker can masquerade himself as a real networkoperator and send spoofed NITZ information to phones.

3G

The 3G specification [6] introduced mandatory mutual au-thentication and integrity protection for signaling messages.Therefore, NITZ information should be processed only whena security setup is present, i.e. after authentication, integrityprotection and the ciphering setup.

4G

The 4G specification [7] introduced further security en-hancements, while retaining security requirement of NITZintroduced in 3G. As a result, NITZ on 4G is only processedafter the authentication and establishment of integrity andciphering, like on 3G.

Unless the attacker breaks 3G or 4G authentication or

15

Operator (Country) 2G/3G 4G

BASE (BE) · ·Mobistar (BE) 3 3

Proximus (BE) 3 3

Vodafone (DE) · ·E-Plus (DE) s s

Telekom (DE) · ·O2 (DE) s ·

Yoigo (ES) 3 3

Bouygues (FR) 3 3

Nova (IS) · ·Siminn (IS) 3 3

Vodafone (IS) 3 ·NTT DoCoMo (JP) · s

SK Telecom (KR) 3 3

KT (KR) 3 3

AT&T (US) · 3

T-Mobile (US) 3 3

Table 1: Operator NITZ policy. Check sign: NITZis sent for all registration, triangle: NITZ is sentinconsistently, dot: NITZ is not sent at all.

the baseband standard is implemented incorrectly, it is im-possible to spoof NITZ messages by masquerading as a realoperator. We utilize implementation problems in certainbasebands later.

4.3.2 Cellular Network Operator Configuration Is-sues

NITZ information is conveyed to the smartphone duringseveral instances such as when it successfully registers tothe network, moves to a different time zone and others men-tioned in [10]. As sending NITZ is an optional feature, cel-lular operators do not send NITZ information regularly tosmartphones. By using our custom tool, we analyzed realnetwork traces during the registration process to determinewhich networks implement the NITZ feature.

Table 1 shows difference of NITZ configuration policiesdeployed by several European, Asian and US cellular oper-ators. Operators with check sign means that the networkis sending NITZ whenever the smartphone registers with it.The rows indicated by a triangle represent the network op-erators who do not have a consistent NITZ policy. In otherwords, these operators are not sending NITZ during everyregistration. The rows marked with a dot mean that thenetwork operators do not send NITZ information at all.

One of the European operators stated that, since most ofthe smartphones today have an Internet connection, they re-ceive their time information via NTP servers which restrainsthem from sending NITZ. The fact that no NITZ informa-tion is sent during registration causes clock synchroniza-tion problems on smartphones. For example, in a scenariowhere a user roams from T-Mobile USA (sending NITZ) toTelekom Germany (not sending NITZ) will not be able to ac-quire clock information automatically. Hence, sending NITZregularly or at least during registration can avoid these prob-lems. In the absence of NITZ, smartphones require a dataconnection to update the clock (via NTP). However manualupdates are still possible.

PhoneNTP →NITZ

NITZ →NTP

Apple iPhone 6S NITZ NITZ

Google Nexus 5 NITZ NITZAsus Zenfone 2E NITZ NITZ

HTC One E9 NITZ NITZHTC One M9 NITZ NTP

Huawei Honor 7 NITZ NITZLG Vu 3 NITZ NITZ

Samsung Galaxy Alpha NITZ NITZSamsung Galaxy S4 NITZ NITZSamsung Galaxy S6 NITZ NITZ

BlackBerry Z10 NITZ NTPLG Fx0 NITZ NITZ

Microsoft Lumia 950 NITZ NTPSamsung Z1 NITZ NTP

Table 2: Priorities of clock sources.

4.3.3 NITZ vs. NTPMost smartphone OS’s such as iOS [1], Android [28, 29],

Windows Phone [36, 38]3 and Firefox OS [52] have multipleclock sources. However, there is no clear standard describ-ing their management. Hence we performed an experimentusing our setup in Section 4.2 to reveal the myths about themanagement and priorities of NITZ and NTP in the testsmartphones.

We set up our test smartphones to retrieve clock infor-mation from the base station, followed by the Wi-Fi accesspoint, and vice versa. We configured the base station andNTP server to send different clock values to check whichclock is preferred. Our results are summarized in Table 2.

Smartphones like the Nexus 5 were reluctant to updatethe clock received over NTP when the clock via NITZ isalready present and was received within the last 24 hours.In other words, an NTP request is only triggered once in 24hours. This behavior is defined in the NTP handling codeof the Android OS [29].

In contrast, certain smartphones are treating NITZ andNTP with equivalent priority, setting the system clock withthe latest received information. For example, the HTC OneM9 updates the clock via NTP in spite of having recentNITZ information. One of the reasons could be the cus-tomized HTC Sense4 environment on Android OS. Althoughthe Lumia 950 also falls in this category, we found that some-times it resets to the accurate clock even when both NITZand NTP are inaccurate. We assume that this is caused byanother clock source which we do not discuss in this paper.

Apple devices running iOS version 9.3.2 behaved differ-ently from most of smartphones. While older version of iOSpreferred NITZ than NTP, newer iOS version changed time-keeping method. It neither accepts new NITZ information,nor issues an NTP request for certain amount of time afterthe clock is set during initial setup or periodic time update.

To summarize, NITZ is given higher priority in most casessince it is received in a secure authenticated channel and canbe trusted more than NTP.

3Prior to Windows Phone 8.1 Update 1 it lacked NTP4HTC customized Android system

16

OS (Architecture) time_t Size End Year

iOS (32-bit) [15] 32-bit 2038iOS (64-bit) 64-bit Never

Android (32-bit)5 32-bit 2038Android (64-bit) 64-bit Never

BlackBerry 10 [18] Unsigned 32-bit 2106Windows [39] Custom 30827

Table 3: Timekeeping method of mobile OS.

4.3.4 Mobile OS issuesMobile OS’s are using different ways to represent internal

clock information as stated in Table 3. For example, 32-bitiOS and Android devices are only able to represent dates upto January 2038 (231 − 1 seconds after UNIX epoch). Anyfuture date causes a clock overflow, and will roll back to thepast. Unintended consequences could happen.

Based on our experiments, sending a clock value (someseconds before 2038-01-19 03:14:07 UTC) via NITZ causesthe mobile OS to crash on all 32-bit Android smartphones.Using NTP to set that clock is not always possible becauseNTP up to version 3 [40] can represent up to year 2036, andmost smartphones utilize NTP version 3. Additionally, 32-bit iPhones like iPhone 5 also suffer from this problem [4].Other 32-bit mobile OS like Firefox OS only rolled back itsinternal clock without crashing. However, the clock on 64-bit smartphones virtually never expires, as 263 − 1 secondsare far beyond the age of the universe.

Baseband OS keeps its time separate from the mobile OS.By using our custom tool we analyzed the baseband times-tamps before and after sending a NITZ message. The Qual-comm basebands has a wider date range than year 2038, butit is not passed to Android due to limitations in the radiocommunication stack. Other basebands like Samsung or In-tel, do not include clock information in debugging messages.

4.4 Spoofing AttacksIn this section, we exploit 3GPP specifications and cellular

operator configuration issues to demonstrate clock spoofingattacks in two ways: via a rogue base station and via a Wi-Fiaccess point.

4.4.1 Via Rogue Base StationWe initially consider that a user’s smartphone is attached

to a legitimate base station. Then attacker forces the phoneto attach to the rogue one (2G/3G/4G), by impersonatingthe user’s service provider. Upon detecting a new base sta-tion the smartphone initiates a connection to it. As a re-sponse the attacker sends spoofed clock information via aMM/GMM/EMM Information message.

On 2G, all our test smartphones accepted spoofed NITZinformation and changed their baseband clock. For 3G and4G, certain smartphones accepted NITZ and changed thebaseband clock in the absence of authentication, thereby vi-olating 3GPP specifications. The received clock informationis forwarded to the mobile OS and used by apps.

Unlike other smartphones, Samsung smartphones (GalaxyAlpha, Galaxy S4, S6, Z1) are changing the time zone of itupon receiving broadcast information such as MCC (Mobile

5including other Linux-based mobile OS, e.g. Firefox OS,Sailfish OS, Tizen

Mobile OS Default NTP Server

Android [0-3].android.pool.ntp.orgBlackBerry 10 time.blackberry.com

Firefox OS [0-3].pool.ntp.orgiOS time-ios.apple.com

Sailfish OS [0-3].sailfishos.pool.ntp.orgTizen pool.ntp.org

Windows time.windows.com

Table 4: Default NTP address for each mobile OS’s.

Country Code) and MNC (Mobile Network Code) from abase station before connecting to it. For example, based onthe MCC and MNC of Vietnam, the time zone is updated toIndochina Time (UTC+07:00). This behavior is unreliabledue to the fact that broadcast messages are accepted by thesmartphone without having any security setup.

As shown in Section 4.3.3, after detaching from the roguebase station the smartphone may or may not receive accu-rate clock information via NITZ depending on the operatorpolicy. Also, an NTP update is unlikely due to the prefer-ence of NITZ over NTP. As a result, we discover that to getaccurate clock some smartphones required a reboot, in somecases even by toggling the automatic clock update feature.

4.4.2 Via Wi-Fi Access PointLike a rogue base station, attacker can operate a rogue

Wi-Fi hotspot with the same name (SSID; Service Set ID)as a legitimate one (e.g. public Wi-Fi). Upon discovery,the smartphone connects to the rogue one and all Internettraffic will be routed via the attacker.

We configured our Wi-Fi access point to redirect all pack-ets towards UDP port 123 (default NTP port) to our rogueNTP server. Upon receiving NTP requests from the smart-phone, the NTP server replied with spoofed clock informa-tion. Because of the wide varieties of NTP server addressesamong mobile OS’s as shown in Table 4, we use a port redi-rection instead of DNS query spoofing for simplicity andscalability of the attack. Since NTP does not mandate anyauthentication, all our tested smartphones accepted spoofedclock information.

Android has an NTP polling interval [29, 27] of one day bydefault. Upon reception of the first NTP response packet,Android will not issue further NTP requests until the NTPpolling interval had been rolled back. This is also true whenthe user changes to the legitimate Wi-Fi network, makingrecovery via NTP impossible at least for one day.

5. IMPACTS ON MOBILE OS AND APPSIn this section, we discuss how clock spoofing attacks af-

fect the operation of baseband and mobile OS and its apps.We also examine the persistence of attacks and possible re-covery methods.

5.1 Baseband OperationsWe analyzed control plane messages in all 2G, 3G, 4G net-

works [9, 11] and found that only a small number of messagescontain current baseband or network clock information. Asa result, most cellular operations are not affected by the at-tack. Other usage of the clock information on the basebandis logging its diagnostic messages.

Signaling messages for telephone calls, both circuit switch

17

Figure 2: Message details on Nexus 5, showing bothnetwork and device timestamp.

based and VoLTE [31], do not contain clock information. Asa result, incoming and outgoing calls are logged on the phonewith the mobile OS clock and operators maintain their ownclock for call accounting.

Incoming SMS is one of the signaling messages contain-ing network clock information when the message has beensent [12]. It is up to the device developers to use the times-tamp present in the incoming SMS or not. Figure 2 showsan example of clock difference: network clock information isincluded in the “Sent” field, the device counterpart is in the“Received” field.

5.2 Mobile OS OperationsClock spoofing can affect various components, ranging

from low level components like kernel and system programsto higher level components like apps.

5.2.1 System ComponentsAny system component or app relying on clock informa-

tion will be vulnerable to spoofing attacks. Specifically,when the attacker sends a date around year 2038 a mem-ory overflow occurs causing a complete system crash. Fur-ther, networking protocols such as TLS/SSL rely on accurateclock information [35].

We concentrate on TLS/SSL as it forms a basis of higherlevel protocols like HTTPS, and is widely used in mobileenvironments. Once a secure connection is established usingTLS, the client performs a server certificate validity periodcheck. If the current clock is outside of the validity period,the certificate is considered to be invalid. Depending onthe type of app, the secure connection gets terminated orestablished nonetheless. We found that Android [30] andiOS [16] enforce strict validity checks on TLS connections,causing a Denial of Service on the smartphone when theclock is incorrect.

5.2.2 AppsWe studied the behavior of apps after the clock spoofing

on Android and iOS. Apps not utilizing clock informationor apps utilizing clock information locally are excluded fromour analysis, because the former is not affected at all andtha later has no means of verifying accuracy of the clock.However, apps utilizing clock information and require a dataconnection are affected by the attack. We tested some ofthe widely used apps and noticed three different behaviors:explicitly noticing clock inaccuracy, showing a generic error

Figure 3: Best practice: screenshot of WhatsAppindicating system clock spoofing.

message, and operate regardless of the clock spoofing.Web browser, social networking, mobile messengers

mainly rely on TLS-based encryption. Specifically, What-sApp (see Figure 3) and Google Chrome explicitly indicatedthe system clock mismatch when clock spoofing was de-tected. In this case, WhatsApp failed to operate normallyuntil the clock was reset to the accurate value.

Further, certain apps like OpenVPN did not distinguishbetween clock spoofing and generic network errors. Figure 4shows how OpenVPN presents an error when the currentsystem clock is outside of the certificate validity period. Appstores like the Google Play Store presented an option to retrythe connection, but this fails to work until the clock is reset.

Finally, certain apps operated regardless of clock spoofingand showed no indication to the user. We observed thisbehavior on apps handling mostly public information likepublic transportation timetable, etc. Samsung Knox [50]also falls into this category, as it allows unlocking and lockingthe secure container regardless of clock spoofing.

5.3 Persistence and RecoveryWe observed that majority of our test smartphones are

affected by the attack, and failed to receive accurate clockinformation even after the attacker shuts down the roguebase station or Wi-Fi access point. During this state, mobileapps failed to operate normally, causing a persistent Denialof Service on the smartphone.

In order to recover, the user needs to reboot the smart-phone. In some cases it is enough to toggle the flight mode.When the user is still in range of the rogue base stationor Wi-Fi access point, rebooting will likely pick up falseclock information again and cause apps to fail. Similarly,when traveling accross time zone, rebooting the smartphoneis usually suggested when current clock information is incor-rect [14].

Rebooting the smartphone would also be required after asystem crash caused by the year 2038 problem. Dependingon the smartphone, the clock resets back to the UNIX timeepoch (year 1970), or before the epoch (year 1901) untilreceiving accurate clock information.

18

Figure 4: Common practice: screenshot of Open-VPN indicating network failure.

6. DISCUSSIONWe now analyze the security implications that arise due

to inadequate timekeeping methods adopted by smartphoneand baseband manufacturers, and mobile OS developers.Further, we propose effective mechanisms to handle clockinformation inside each component of smartphones.

Baseband manufacturers. As the mobile OS prefersto receive clock information over NITZ assuming that itis acquired over a secure channel, baseband manufacturersshould abide by the security measures already implementedin respective specifications for NITZ.

Moreover, as operating a rogue base station now becameeasier [20], baseband manufacturers are required to applydefensive programming regarding the data received fromthe network provider. An example of defensive program-ming would be to verify the received NITZ values. The3GPP specification does not clearly define error handlingprocedures when NITZ information contains an invalid clockvalue [9, 12]. As a result, when the base station sends month13, it could be interpreted as next year January or could beignored. Likewise, hour 25 could be interpreted as 01:00next day. All these behaviors are accepted. Some basebandaccepted out-of-range values and interpreted them as a timein the future, while some ignored those values. As the clockinformation first arrives on the baseband processor, a sanitycheck will release the burden of verifying the data inside themobile OS.

Mobile OS developers. OS need to provide consistentand predictable policies on clock updates. As clock sourceshave different availability and security, more available andsecure clock sources should always be preferred. Also, mo-bile OS can provide interfaces to trigger manual updates ofthe clock, and a minimal notification of the current clocksource when the clock source had been changed. For exam-ple, BlackBerry has an option to ask the user about timezone updates when a new time zone is detected [19]. Thiscan save the user from rebooting the phone when travelingacross time zones, and gives user the chance to use a manualclock when some of the clock sources are not working.

Recent Apple iOS 9.3 series introduced some of the san-itization mentioned in Section 4.3.3. Contrary to iOS, ourtest Android smartphones changed its clock when there werea large clock drift. Although Android has some NITZ san-itization procedures [28] but it only checks system uptimeupon receiving NITZ, not the content of NITZ information.As a result, mobile OS clock changed in cases when we senta correct time value first (e.g. 1st July midnight), then atime value of some days in the future or past (e.g. 10th Julyor 20th June), and then again recovered the original time(e.g. 1st July 00:10).

Although iPhone 5s opened the era of 64-bit smartphonesin July 2013, a large number of 32-bit smartphones and cel-lular capable M2M and IoT devices will remain in operationfor an extended amount of time. Therefore, OS developersshould be aware of the year 2038 problem and need to pro-vide fallback mechanisms without causing the OS to crash.Although the problem itself was first reported on Android 5years ago [2], the bug was virtually abandoned and remainedhidden for a long time.

Additionally, OS developers and/or device manufactur-ers can implement secure NTP to protect users from NTPspoofing attacks. NTP version 4 introduced cryptographicauthentication features, and there are studies proposing se-cure NTP [24]. Authenticated NTP is already in operationby NIST [44] and the US Naval Observatory [45]. Somedevice manufacturers like Apple and BlackBerry are oper-ating NTP servers themselves, and actively utilizing securecontainers in their respective mobile OS. They can provideNTP with authentication as a premium service.

App developers. Among our set of test apps, What-sApp and Google Chrome showed the best way to handlethe clock spoofing. Other apps using TLS did not distin-guish correctly between errors caused by clock spoofing fromgeneric network errors. Unlike other network errors, errorscaused by clock spoofing are easier to detect and recoverfrom by the user. We therefore suggest app developers todistinguish clock spoofing errors from other errors, unlessthe app is not utilizing clock information.

Also, if clock information is extensively used inside an app,operating a separate time server on the app developer’s sidecan help making accurate timekeeping less of an issue insidethe application. Some time-critical apps like banking appsare already following this.

App developers can differentiate certificate validity pe-riod, compromising between security and maintenance cost.Google set their certificate validity to 3 months, while Face-book and Twitter used 2 years. As a result, Google apps arestricter on clock spoofing attacks as compared to Facebookand Twitter.

7. CONCLUDING REMARKS AND FU-TURE WORK

Smartphones are utilizing multiple clock sources via cel-lular network and Internet to ensure accurate clock infor-mation. We have shown that the vulnerabilities we discov-ered in cellular network (2G, 3G and 4G), NTP standards,and implementations allowed clock spoofing attack towardssmartphone users. Our attacks were performed using opensource cellular network and NTP server software, with read-ily available hardware and several smartphones with 6 differ-ent mobile OS’s. We demonstrated Denial of Service attack

19

leading to the malfunction of apps and complete mobile OScrash. Baseband implementations, 3GPP standard issues,and lack of consistent timekeeping methods in smartphonesare the root causes of these attacks. We proposed best prac-tices to manage multiple clock sources in smartphones andprovide accurate clock to the user. We followed standard re-sponsible disclosure methods of all affected manufacturers,and we also notified the mobile app developers and OS de-velopers. Google addressed the problem mentioned in thispaper in Android Security Bulletin, August 2016 [26, 5].

Our future work will cover the other clock sources we ex-cluded or did not analyzed in this paper, and the othercomponents of mobile OS and apps. Although we explic-itly excluded GPS in this paper, GPS spoofing includingclock information is already proposed [54]. While previouswork [35] mentioned that multiple protocols are affected byclock spoofing attack, we only covered TLS/SSL in this pa-per. We will also cover other network protocols and OScomponents that is largely affected by clock spoofing attack.

We belive our attacks are not only true for smartphonesbut also for IoT systems that derive from a mobile OS (forexample, connected cars). There is more protection and reli-ability needed for maintaining an accurate time informationfor these systems. Our research results exhibit that clockspoofing attacks needs more attention in the age of digitallyconnected world.

AcknowledgementsThis research was partly performed within the 5G-ENSUREproject (www.5GEnsure.eu) the EU Framework Programmefor Research and Innovation Horizon 2020 under grant agree-ment no. 671562 and received funding from the SoftwareCampus project from DLR (Deutsches Zentrum fur Luft-und Raumfahrt) project no. 01IS12056. We would like tothank Kibum Choi, Byeongdo Hong, Dongkwan Kim, HongilKim and Youngseok Park from KAIST on collection of data,and the anonymous reviewers for their thoughtful feedbackon previous versions of this paper.

8. REFERENCES[1] Carrier.plist - The iPhone Wiki.

https://www.theiphonewiki.com/wiki/Carrier.plist.

[2] Issue 16899: Year 2038 problem - Android OpenSource Project Issue Tracker. https://code.google.com/p/android/issues/detail?id=16899.

[3] pool.ntp.org project : the internet cluster of ntpservers. http://www.pool.ntp.org/en/.

[4] The iPhone Apocalypse: January 19, 2038 -MacRumors Forums.http://forums.macrumors.com/threads/the-iphone-apocalypse-january-19-2038.1943912/.

[5] CVE-2016-3831. Available from MITRE, CVE-IDCVE-2016-3831., 2016.

[6] 3GPP. 3G security; Security architecture. TS 33.102,3rd Generation Partnership Project (3GPP).

[7] 3GPP. 3GPP System Architecture Evolution (SAE);Security architecture. TS 33.401, 3rd GenerationPartnership Project (3GPP).

[8] 3GPP. Digital cellular telecommunications system(Phase 2+); Security aspects. TS 42.009, 3rdGeneration Partnership Project (3GPP).

[9] 3GPP. Mobile radio interface Layer 3 specification;Core network protocols; Stage 3. TS 24.008, 3rdGeneration Partnership Project (3GPP).

[10] 3GPP. Network Identity and TimeZone (NITZ);Service description; Stage 1. TS 22.042, 3rdGeneration Partnership Project (3GPP).

[11] 3GPP. Non-Access-Stratum (NAS) protocol forEvolved Packet System (EPS); Stage 3. TS 24.301,3rd Generation Partnership Project (3GPP).

[12] 3GPP. Technical realization of the Short MessageService (SMS). TS 23.040, 3rd Generation PartnershipProject (3GPP).

[13] B. Alecu. SMS Fuzzing - SIM Toolkit Attack. DEFCON 21, 2013.

[14] AndroidCentral.com. Automatic time zone anddate/clock are wrong.http://forums.androidcentral.com/htc-one-m7/291916-automatic-time-zone-date-clock-wrong.html.

[15] Apple Inc. Major 64-Bit Changes - iOS DeveloperLibrary. https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/Major64-BitChanges/Major64-BitChanges.html.

[16] Apple Inc. Using Network Securely - iOS DeveloperLibrary. https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/SecureNetworking/SecureNetworking.html.

[17] Apple Support. If you changed the date to May 1970or earlier and can’t restart your iPhone, iPad, or iPodtouch. https://support.apple.com/en-us/HT205248.

[18] BlackBerry Limited. Clock and timer services - NativeSDK for BlackBerry 10. https://developer.blackberry.com/native/documentation/dev/rtos/arch/kernel clockandtimer.html.

[19] BlackBerry Limited. When traveling between timezones the BlackBerry smartphone does notautomatically update to local time.http://support.blackberry.com/kb/articleDetail?ArticleNumber=000010323.

[20] R. Borgaonkar, K. Redon, and J.-P. Seifert. Securityanalysis of a femtocell device. In Proceedings of the 4thInternational Conference on Security of Informationand Networks, SIN ’11, pages 95–102, New York, NY,USA, 2011. ACM.

[21] Bruce Perens et al. BusyBox.https://busybox.net/about.html.

[22] Cinterion Wireless Modules. BGS2-E AT CommandSpecification.

[23] J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos,M. Bailey, and M. Karir. Taming the 800 PoundGorilla: The Rise and Decline of NTP DDoS Attacks.In Proceedings of the 2014 Conference on InternetMeasurement Conference, IMC ’14. ACM, 2014.

[24] B. Dowling, D. Stebila, and G. Zaverucha.Authenticated network time synchronization. IACRCryptology ePrint Archive, 2015:171, 2015.

[25] D. Goodin. New DoS attacks taking down game sitesdeliver crippling 100Gbps floods.

http://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-

20

gbps-floods/.

[26] Google Inc. Android Security Bulletin–August 2016.https://source.android.com/security/bulletin/2016-08-01.html.

[27] Google Inc. config.xml. https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/values/config.xml.

[28] Google Inc. GsmServiceStateTracker.java. https://android.googlesource.com/platform/frameworks/opt/telephony/+/master/src/java/com/android/internal/telephony/gsm/GsmServiceStateTracker.java.

[29] Google Inc. NetworkTimeUpdateService.java.https://android.googlesource.com/platform/frameworks/base.git/+/master/services/core/java/com/android/server/NetworkTimeUpdateService.java.

[30] Google Inc. Security with HTTPS and SSL - AndroidDevelopers. http://developer.android.com/training/articles/security-ssl.html.

[31] GSMA. Official Document IR.92 - IMS Profile forVoice and SMS.

[32] P. Kelley and M. Harrigan. iOS 1970 VulnerabilityLeads to Remote Bricking of Phones Over The Air.https://www.youtube.com/watch?v=zivWTwOjEME.

[33] J. Klein. Becoming a Time Lord: Implications ofAttacking Time Sources. Shmoocon FireTalks 2013,2013.

[34] D. F. Kune, J. Kolndorfer, N. Hopper, and Y. Kim.Location leaks over the GSM air interface. 19thAnnual Network and Distributed System SecuritySymposium, NDSS 2012, San Diego, California, USA,February 5-8, 2012, 2012.

[35] A. Malhotra, I. E. Cohen, E. Brakke, and S. Goldberg.Attacking the Network Time Protocol. In 23rd AnnualNetwork and Distributed System Security Symposium,NDSS 2016, 2016.

[36] Microsoft. EnableAutomaticTime - Windows 10hardware dev. https://msdn.microsoft.com/en-us/library/windows/hardware/mt502640(v=vs.85).aspx.

[37] Microsoft. FILETIME structure - Windows DevCenter. https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx.

[38] Microsoft. NTPEnabled - Windows 10 hardware dev.https://msdn.microsoft.com/en-us/library/windows/hardware/mt157027(v=vs.85).aspx.

[39] Microsoft. SYSTEMTIME structure - Windows DevCenter. https://msdn.microsoft.com/en-us/library/windows/desktop/ms724950%28v=vs.85%29.aspx.

[40] D. Mills. Network Time Protocol (Version 3)Specification, Implementation and Analysis. RFC 1305(Draft Standard), Mar. 1992. Obsoleted by RFC 5905.

[41] D. Mills, J. Martin, J. Burbank, and W. Kasch.Network Time Protocol Version 4: Protocol andAlgorithms Specification. RFC 5905 (ProposedStandard), June 2010.

[42] C. Mulliner, N. Golde, and J.-P. Seifert. SMS ofDeath: from analyzing to attacking mobile phones ona large scale. USENIX Security, 2011.

[43] S. Musil. Smartwatches now more popular than Swisswatches, thanks to Apple. CNET, 2016.

[44] National Institute of Standards and Technology. TheNIST Authenticated NTP Service. http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm.

[45] Naval Meteorology and Oceanography Command.Authenticated NTP - DoD Customers. http://www.usno.navy.mil/USNO/time/ntp/dod-customers.

[46] M. Prince. Technical Details Behind a 400Gbps NTPAmplification DDoS Attack.https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/.

[47] Range Networks. OpenBTS. http://openbts.org/.

[48] Range Networks. OpenBTS-UMTS. http://openbts.org/w/index.php?title=OpenBTS-UMTS.

[49] S. Rottger. Finding and exploiting ntpdvulnerabilities. http://googleprojectzero.blogspot.de/2015/01/finding-and-exploiting-ntpd.html.

[50] Samsung. Mobile Enterprise Security – SamsungKnox. https://www.samsungknox.com/en.

[51] A. Shaik, R. Borgaonkar, N. Asokan, V. Niemi, andJ.-P. Seifert. Practical attacks against privacy andavailability in 4G/LTE mobile communicationsystems. In 23rd Annual Network and DistributedSystem Security Symposium, NDSS San Diego,California, USA, February 21-24, 2016, 2016.

[52] Shao Hang Kao. Bug 874771 - Implement SNTPsupport (Gecko end). https://hg.mozilla.org/mozilla-central/rev/fb5ba2a8e039.

[53] Z. Straley. Don’t set your iPhone’s date to January 1,1970! The fastest trick to BRICK an iPhone!https://www.youtube.com/watch?v=fY-ahR1R6IE.

[54] N. O. Tippenhauer, C. Popper, K. B. Rasmussen, andS. Capkun. On the Requirements for Successful GPSSpoofing Attacks. In Proceedings of the 18th ACMConference on Computer and CommunicationsSecurity, CCS, 2011.

[55] R.-P. Weinmann. Baseband Attacks: RemoteExploitation of Memory Corruptions in CellularProtocol Stacks. USENIX Workshop on OffensiveTechnologies, 2012.

[56] B. Wojtowicz. OpenLTE.https://sourceforge.net/projects/openlte/.

[57] Y. Zheng and H. Shan. Time is On My Side: Forginga Wireless Time Signal to Attack NTP Servers. HITB2016 Amsterdam, 2016.

http://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-

21