Tricking AI - lessons for surveillance cameras

Fooling automated surveillance cameras: adversarial patches to attack person detection

WATCH THE VIDEO

Adversarial attacks on machine learning models have seen increasing interest in the past years. By making only subtle changes to the input of a convolutional neural network, the output of the network can be swayed to output a completely different result. The first attacks did this by changing pixel values of an input image slightly to fool a classifier to output the wrong class. Other approaches have tried to learn "patches" that can be applied to an object to fool detectors and classifiers. Some of these approaches have also shown that these attacks are feasible in the real-world, i.e. by modifying an object and filming it with a video camera. However, all of these approaches target classes that contain almost no intra-class variety (e.g. stop signs). The known structure of the object is then used to generate an adversarial patch on top of it.

In this paper, we present an approach to generate adversarial patches to targets with lots of intra-class variety, namely persons. The goal is to generate a patch that is able successfully hide a person from a person detector. An attack that could for instance be used maliciously to circumvent surveillance systems, intruders can sneak around undetected by holding a small cardboard plate in front of their body aimed towards the surveillance camera.

From our results we can see that our system is able significantly lower the accuracy of a person detector. Our approach also functions well in real-life scenarios where the patch is filmed by a camera. To the best of our knowledge we are the first to attempt this kind of attack on targets with a high level of intra-class variety like persons.

The research - https://arxiv.org/abs/1904.08653
Download coding - https://gitlab.com/EAVISE/adversarial-yolo

5G-NR False Base Stations (Part 2)

Going forward with further discussions about FBS (false base stations) considering detection and prevention approaches that can be taken to act as a deterrent against them or their use; it is inescapable thus unavoidable that readers need to be aware of the meanings of abbreviations and definitions adopted for 5G and the reason for my trewmte blog look-up reference. This doesn't suggest you shouldn't go and get the appropriate reference materials (https://www.3gpp.org/about-3gpp), but its easier to get people interested and engaged in a subject without further procedures needed to be followed.

For the record, the reference materials relevant to this discussion are the following 3GPP documents:

[1] 3GPP TS 33.501 5G; Security architecture and procedures for 5G System
[2] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications"

TS = Technical Standards
TR= Technical Report

In [1] it includes the statement:  'For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [2] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905.' Hence why I refer below to the abbreviations and definitions in [1].

ABBREVIATIONS
5GC 5G Core Network
5G-AN 5G Access Network
5G-RAN 5G Radio Access Network
5G AV 5G Authentication Vector
5G HE AV 5G Home Environment Authentication Vector
AES Advanced Encryption Standard
AKA Authentication and Key Agreement
AMF Access and Mobility Management Function
AMF Authentication Management Field
NOTE: If necessary, the full word is spelled out to disambiguate the abbreviation.
ARPF Authentication credential Repository and Processing Function
AUSF Authentication Server Function
AUTN AUthentication TokeN
AV Authentication Vector
AV' transformed Authentication Vector
CP Control Plane
CTR Counter (mode)
CU Central Unit
DN Data Network
DNN Data Network Name
DU Distributed Unit
EAP Extensible Authentication Protocol
EMSK Extended Master Session Key
EPS Evolved Packet System
gNB NR Node B
GUTI Globally Unique Temporary UE Identity
HRES Hash RESponse
HXRES Hash eXpected RESponse
IKE Internet Key Exchange
KSI Key Set Identifier
LI Lawful Intercept
MN Master Node
MR-DC Multi-RAT Dual Connectivity
MSK Master Session Key
N3IWF Non-3GPP access InterWorking Function
NAI Network Access Identifier
NAS Non Access Stratum
NDS Network Domain Security
NEA NR Encryption Algorithm for 5G
NF Network Function
NG Next Generation
ng-eNB Next Generation Evolved Node-B
ngKSI Key Set Identifier in 5G
NIA NR Integrity Algorithm for 5G
NR New Radio
NSSAI Network Slice Selection Assistance Information
PDN Packet Data Network
PEI Permanent Equipment Identifier
QoS Quality of Service
RES RESponse
SCG Secondary Cell Group
SEAF SEcurity Anchor Function
SEG Security Gateway
SIDF Subscription Identifier De-concealing Function
SMC Security Mode Command
SMF Session Management Function
SN Secondary Node
SN Id Serving Network Identifier
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
TLS Transport Layer Security
UE User Equipment
UEA UMTS Encryption Algorithm
UDM Unified Data Management
UIA UMTS Integrity Algorithm
ULR Update Location Request
UP User Plane
UPF User Plane Function
USIM Universal Subscriber Identity Module
XRES eXpected RESponse

DEFINITIONS

Within the 3GPP Specifications under the heading 'Definitions' invariably the reader finds references to other specifications. A reference to a standard is helpful, but it is also even more helpful to know the identification of the technology or the system the specification relates. To this end 3GPP identify 20 subjects in its index of which 2 are historical references backdated to the start of GSM, which I have eliminate those from the table above, and focussed on 18 subjects most commonly referred to today.

So when you read a definition below that includes a reference to a specification, such as "Master node: As defined in TS 37.340" just look at the table above to determine the subject that is relevant to discussions about Master node, which in this case is 'Multiple radio access technology aspects 37 series'.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
5G security context: The state that is established locally at the UE and a serving network domain and represented by the "5G security context data" stored at the UE and a serving network.
NOTE 1: The "5G security context data" consists of the 5G NAS security context, and the 5G AS security context for 3GPP access and/or the 5G AS security context for non-3GPP access.

NOTE 2: A 5G security context has type "mapped", "full native" or "partial native". Its state can either be "current" or "non-current". A context can be of one type only and be in one state at a time. The state of a particular context type can change over time. A partial native context can be transformed into a full native. No other type transformations are possible.


5G AS security context for 3GPP access: The cryptographic keys at AS level with their identifiers, the Next Hop parameter (NH), the Next Hop Chaining Counter parameter (NCC) used for next hop access key derivation, the identifiers of the selected AS level cryptographic algorithms, and the counters used for replay protection.
NOTE 3: NH and NCC need to be stored also at the AMF during connected mode.

5G AS security context for non-3GPP access: The key KN3IWF, the cryptographic keys, cryptographic algorithms and tunnel security association parameters used at IPsec layer for the protection of IPsec SA.

5G Authentication Vector: a vector consisting of RAND, AUTN, XRES*, and KAUSF for the purpose of authenticating the UE using 5G AKA.
NOTE 3a: This vector is received by the AUSF from the UDM/ARPF in the Nudm_Authentication_Get Response.

5G Home Environment Authentication Vector: a vector consisting of RAND, AUTN, HXRES*, and KSEAF.
NOTE 3b: This vector is received by the SEAF from the AUSF in the Nausf_Authentication_Authenticate Response.

5G NAS security context: The key KAMF with the associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values.
NOTE 4: The distinction between native 5G security context and mapped 5G security context also applies to 5G NAS security contexts. The 5G NAS security context is called "full" if it additionally contains the integrity and encryption keys and the associated identifiers of the selected NAS integrity and encryption algorithms.

activation of security context: The process of taking a security context into use.

anchor key: The security key KSEAF provided during authentication and used for derivation of subsequent security keys.


authentication vector: a vector consisting of CK, IK, RAND, AUTN, and XRES.


authentication data: 5G Authentication Vector or transformed authentication vector.


backward security: The property that for an entity with knowledge of Kn, it is computationally infeasible to compute any previous Kn-m (m>0) from which Kn is derived.
NOTE 5: In the context of KgNB key derivation, backward security refers to the property that, for a gNB with knowledge of a KgNB, shared with a UE, it is computationally infeasible to compute any previous KgNB that has been used between the same UE and a previous gNB.

CM-CONNECTED state: This is as defined in TS 23.501 [2].
NOTE5a: The term CM-CONNECTED state corresponds to the term 5GMM-CONNECTED mode used in TS 24.501

CM-IDLE state: As defined in TS 23.501.
NOTE5b: The term CM-IDLE state corresponds to the term 5GMM-IDLE mode used in TS 24.501.

current 5G security context: The security context which has been activated most recently.
NOTE5c: A current 5G security context originating from either a mapped or native 5G security context can exist simultaneously with a native non-current 5G security context.

forward security: The fulfilment of the property that for an entity with knowledge of Km that is used between that entity and a second entity, it is computationally infeasible to predict any future Km+n (n>0) used between a third entity and the second entity.
NOTE 6: In the context of KgNB key derivation, forward security refers to the property that, for a gNB with knowledge of a KgNB, shared with a UE, it is computationally infeasible to predict any future KgNB that will be used between the same UE and another gNB. More specifically, n hop forward security refers to the property that a gNB is unable to compute keys that will be used between a UE and another gNB to which the UE is connected after n or more handovers (n=1 or more).

full native 5G security context: A native 5G security context for which the 5G NAS security context is full according to the above definition.
NOTE6a: A full native 5G security context is either in state "current" or state "non-current".

Mapped 5G security context: An 5G security context, whose KAMF was derived from EPS keys during interworking and which is identified by mapped ngKSI.

native 5G security context: An 5G security context, whose KAMF was created by a run of primary authentication and which is identified by native ngKSI.


non-current 5G security context: A native 5G security context that is not the current one.
NOTE 7: A non-current 5G security context may be stored along with a current 5G security context in the UE and the AMF. A non-current 5G security context does not contain 5G AS security context. A non-current 5G security context is either of type "full native" or of type "partial native". partial native 5G security context: A partial native 5G security context consists of KAMF with the associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values, which are initially set to zero before the first NAS SMC procedure for this security context.
NOTE 8: A partial native 5G security context is created by primary authentication, for which no corresponding successful NAS SMC has been run. A partial native context is always in state "non-current".

RM-DEREGISTERED state: This is as defined in TS 23.501.
NOTE8a: The term RM-DEREGISTERED state corresponds to the term 5GMM-DEREGISTERED mode used in TS 24.501.

RM-REGISTERED state: As defined in TS 23.501.
NOTE8b: The term RM-REGISTERED state corresponds to the term 5GMM-REGISTERED mode used in TS 24.501.

subscription identifier: The SUbscription Permanent Identifier (SUPI) is defined in TS 23.501.


subscription identifier de-concealing function: The Subscription Identifier De-concealing Function (SIDF) service offered by the network function UDM in the home network of the subscriber responsible for de-concealing the SUPI from the SUCI.


subscription concealed identifier: A one-time use subscription identifier, called The SUbscription Concealed Identifier (SUCI), which contains the concealed subscription identifier, e.g. the MSIN part of SUPI, and additional non-concealed information needed for home network routing and protection scheme usage.

security anchor function: The function that serves as the anchor for security in 5G.

subscription credential(s): The set of values in the USIM and the ARPF, consisting of at least the long-term key(s) and the subscription identifier SUPI, used to uniquely identify a subscription and to mutually authenticate the UE and 5G core network.

transformed authentication vector: an authentication vector where CK and IK have been replaced with CK' and IK'.

UE security capabilities: The set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE.
NOTE 9: This includes capabilities for NG-RAN and 5G NAS, and includes capabilities for EPS, UTRAN and GERAN if these access types are supported by the UE.

UE 5G security capability: The UE security capabilities for 5G AS and 5G NAS.
Master node: As defined in TS 37.340.

ng-eNB: As defined in TS 38.300.

Secondary node: As defined in TS 37.340.

AS Secondary Cell security context: This context consists of the cryptographic keys for SN (KUPenc), the identifier of the selected AS SC level cryptographic algorithm and counters used for replay protection.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-


IN CLOSING
It may not seem obvious just yet from all the abbreviation and definitions (above) but they will be discussed in future Parts of these blog discussions. In relation to false base stations the standards, specifications and reports are not merely concerned with detecting and preventing their usage, but equally to have concern if such FBSs were to successful create a trap for genuine UEs and act as a conduit MiTM (man-in-the-middle) attack would the FBSs be able to decrypt and decipher encrypted signalling and communications directed between the Network and UE?

For the moment, at least, in one webpage and without tracking down and downloading the complete standard, readers can see at a glance on this look-up page 5G security references and what 3GPP intends how they should be understood.

5G-NR False Base Stations (Part 1)

This is my first technology post for a while at trewmte blogspot as my time in research now extends to 5G-NR; network investigations; connected cars and autonomous vehicles; drones; in addition to existing digital forensics, smartphone examinations and cell site analysis. I have a number new insights and revelations for readers this year about the aforementioned subjects. So I will be more active on the blog.

5G False Base Stations (Part 1)
With 5G-NR (new radio) now in limited use and operators in pursuit to increase its usage and, at some point, replace 2G and 3G, it has not escaped the notice of those creating mobile and data networks the need for security. Given the slew of research into networks and devices susceptible to MiTM (man-in-the-middle) attacks it isn't a surprise to find forum conversations about possible attacks by 5G-NR false base stations.

As a quick technical reference for a 5G-NR base station it is defined by "gNB" = g that it is directing communications and signalling to a 5G network via an NB = Node B (the base station). This quick reference does not replace or take precedence over the definition 5G-NR base station as recorded in the 3GPP Standards; so always refer to the standards as your reference point as my comments are evangelistic-observations on the subject and those observations are made to quickly shoehorn readers into this discussion.

Other Side of the Coin
Some may think that little has been done by network operators/standards bodies confirming measures taken to assuage mobile users that once a false base station is in use (MiTM) that nothing can be done and an attack or crime succeeds un-impeded. This is not only wrong and misguided viewpoint, worst still it would be untrue. As an example of just one deployable security method there is a case for active participation (not visible to the mobile user) between the UE (user equipment) and the network termed "UE-assisted network-based detection of false base station".

Preamble
The UE in RRC_CONNECTED mode sends measurement reports to the network in accordance with the measurement configuration provided by the network. These measurement reports have security values in being useful for detection of false base stations or SUPI/5G-GUTI catchers (as an example IMSI catchers). Mobile network operators, using an implementation specific process/procedure, may choose UEs or tracking areas or duration for which measurement reports are to be analysed for detection of false base station. So measurement reports from UEs can be used for detection of false base station, and some additional actions thereafter.

What Type of Content is in a Measurement Report
Examples given are the received-signal strength and location information in measurement reports can be used to detect a false base station that attract UEs which it does by transmitting signal with higher power than those genuine base stations surrounding the UEs.

Measurement reports can also be used to detect a false base stations that replays genuine information blocks (MIB/SIB) without modification. In order to detect a false base station which replays modified version of broadcast information to prevent victim UEs from switching back and forth between itself and genuine base stations (e.g. modifying neighbouring cells, cell reselection criteria, registration timers, etc. to avoid the so called ping-pong effect), information on broadcast information can be used to detect inconsistency from the deployment information.

It is known a false base station which uses inconsistent cell identifier or operates in inconsistent frequency than the deployment of the genuine base stations can be detected respectively by using the cell identifier or the frequency information in the measurement reports.

Moreover, MiTM attackers deploying a false base station may deploy rogue UEs to assist in the attack by attempting to trick the network. Measurement reports collected from multiple UEs in an area can be used to filter out incorrect reports sent by a potential rogue UE.

It doesn't automatically follow when reading forum posts or discussions about attackers and false base stations that they (both) are somehow undetectable.

I will be posting more on this subject given this is Part 1).