In case of sequence synchronization failure, why doesn't USIM use the AMF value received from the network to calculate the AUTS via f1* function, instead 0x0000 is set for AMF for calculating AUTS for both UMTS and E-UTRAN?
ETSI TS 133 102 says:
The AMF used to calculate MAC-S assumes a dummy value of all zeros so that it does not need to be transmitted in the clear in the re-synch message.
However, what I don't fully understand is why would that matter? Wasn't the AMF sent in clear format previously in the signalings?
LTE security / Gunther Horn ... [et al.]. – 2nd edition states:
AUTS is included in an Authentication Failure message from the UE to the MME. The MME forwards AUTS to the HSS requesting new AVs. The AMF used to calculate MAC-S is set to all zeros so that it does not need to be transmitted back to the HSS.
If AMF was not set to 0x0000, then AuC would have to inform HSS? If so, why?
Related
In AUTOSAR E2E Profile1, the counter max value is fixed as 0x0E. But what if we want to change it to 0xF? Any side effect? is there any consideration to skip the 0xF in the original AUTOSAR standard?
I checked the AUTOSAR_SWS_E2ELibrary.pdf, it only says 0xF is a invalid value to be skipped. But why is it an invalid value? waht's the consequences if we not skip the 0xF?
One of my customer insist to use the 0xF unless we can show them the side effects.
The value 0x0F is meant as "invalid value", which means, even though the message was transmitted (by Com out of its message buffer initialized at Com_Init()), it might be default inital data, and SWC was not running, and therefore not updating the data. That can be found out by the receiver, because of the invalid.
Changing this and using 0x0F as valid value means, you are violating the standardized E2E Profile1. If the E2E Profile1 is specified in the SystemDescription to be used, every communication partner does rely on E2E Profile1 as specified in AUTOSAR, not your "we use 0xF as valid" implementation and will fail.
Not sure, why your customer relies on 0x0F being a valid value for E2E Profile1. Tell him, this violates AUTOSAR.
I've been working doing some reverse engineering to different BLE based devices and I have a weight scale where I can't find a pattern to find/decode/interpret the weight value that I can get from the android app. I was also able to get the services and characteristics of this device but did not found a SIG standard match with the UUIDs from the bluetooth site.
I'm using an nRF51 dongle to sniffing data packets between the android app and the weight scale and I can look the ble traffic, but there are several events during the communication that I can't really understand what's the relation and I can't be able to convert those values to readable weight in kg or pounds.
My target value is: 71.3kg readed from the weight scale app.
Let me show you what I get from the ble sniffer.
first I see that the master is sending notification/indication requests to the handles 0x0009(notify), 0x000c(indication) and 0x000f(notify) in each characteristic of one service.
Then I start to read notification/indications values mixed with write commands. At the end of the communication, I see some packets that I feel that they are the ones with the weight scale data and BMI.
Packets number 574, 672 and 674 in the image.
So that give us the following candidates:
1st. packet_number_574 = '000002c9070002
2nd. packet_number_672 = '420001000000005ed12059007f02c9011d01f101'
3rd. packet_number_674 = '42018c016b00070237057d001a01bc001d007c'
1st packet during the communication exchange looks more like a counter/RT/clock than a real measurement because of the data behavior, so I feel this one is not a real option.
2nd and 3rd looks more like real candidates, I have split them and convert them to decimal values and I have not found a relation, even combining bytes since this values are floating point data types. So my real question is, Am I missing something that you might see with this information? Do you know if there is a relation between this data packets and my target?
Thank you for taking your time reading me and any help could be good, thanks!
EDIT:
I have a python script that allows me to check the services and their characteristics hierarchy and some useful data like properties, their handles and descriptors.
Service 'fff0' (0000fff0-0000-1000-8000-00805f9b34fb):
Characteristic 'fff1' (0000fff1-0000-1000-8000-00805f9b34fb):
Handle: 8 (8)
Readable: False
Pro+perties: WRITE NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0x9; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff2' (0000fff2-0000-1000-8000-00805f9b34fb):
Handle: 11 (b)
Readable: False
Properties: WRITE NO RESPONSE INDICATE
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xc; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff3' (0000fff3-0000-1000-8000-00805f9b34fb):
Handle: 14 (e)
Readable: False
Properties: NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xf; uuid 00002902-0000-1000-8000-00805f9b34fb)
This are the characteristics related to the notifications and indications that I see in wireshark. I think the packet number 574 (which characteristics has only a notifiy property) is more important than I think.
I solve it by myself.
This post gives me the idea to take the values (2 bytes) and multiply them by 0.1, that way I could get the weight.
In bytes I could look for my target value without decimals 713, which is in hex = 0x02c9
If we look at the packet number 574:
000002c9070002 and split it 00:00:02:c9:07:00:02
I could see that 2nd and 3rd bytes match with this pattern!
The only thing required to do is to group this bytes and multiply the decimal value 713 x 0.1 = 71.3. I made different tests and found that this pattern is constant so I feel is accurate for my solution. Hope this could help someone in the future.
I feel like both are used to identify logical channel that a physical channel is divided into. Is there any difference?
Short answer:
Both terms are relevant to Bluetooth Logical Links definitions.
LT Address is defined in Link Control; it is being used In the packet header.
In general, It allows a Bluetooth (BR/EDR) slave to determine that a certain packet was addressed to it.
LLID is defined in the packet payload header and is used to distinguish between:
ACL-C (Link Management Protocol) message
ACL-U (L2CAP - Logical Link Control and Adaptation Protocol) message
Detailed answer (all page references address the BT Spec 5.0):
LT Address is defined in the Bluetooth Baseband Specification and stands for Logical Transport Address.
It is defined in Link Control layer for the master to be able to address its various slaves within the piconet.
Each slave is assigned with a unique 3-bit LT_ADDR (page 390):
The primary LT_ADDR shall be assigned by the master to the slave when
the slave is activated. This is either at connection establishment or
role switch, when the primary LT_ADDR is carried in the FHS payload.
LLID term is defined in ACL-C and ACL-U (=> L2CAP) logical links:
It is included in the packet payload header to determine if a packet is ACL-C (LMP) or ACL-U (L2CAP):
ACL-C (page 398):
The ACL-C and ASB-C logical links are indicated by the LLID code 11b
in the payload header.
ACL-U (page 399):
For fragmented messages, the start packet shall use anLLID code of
10b in the payload header. Remaining continuation packets shall use
LLID code 01b. If there is no fragmentation, all packets shall use
the LLID start code 10b.
There’s another usage of the LLID term in context of Bluetooth Low Energy (LE) which is not covered here.
The Logical Link Control and Adaptation Layer Protocol (L2CAP) is layered over the Baseband Protocol and resides in the data link layer. It provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.
Fig1: L2CAP architecture block
Link Controller (LC)
The standard data packet used at the LC level comprises an Access Code, Packet Header, Payload Header, Payload and CRC. This standard packet will be used to encompass data to and from the upper-layers of the protocol stack.
Fig1: Packet structure at LC
Packet Header
Header comprises of six fields LT_ADDR,TYPE,FLOW,ARQN,SEQN and HEC
LT_ADDR (Logical Transport Address) : LT_ADDR comprises of a 3-bit field, which denotes an active slave within a piconet (Note: that the master is not assigned a LT_ADDR).
Payload
LLID (Logical Link Identifier) : Within such logical transports, the logical link is identified by the LLID bits in the payload header of baseband packets that carry a data payload.
Ref :
BLE5-Stack User's Guide
Developing Practical Wireless Applications
Bluetooth Specification - Vol 0
I read about SECURITY_MODE_COMMAND that it's sent by the NW to stop/start enciphering of messages.
I could not find in SECURITY_MODE_COMMAND message structure what fields I need to check in order to find out if ciphering should begin or should end.
Can I get some help with that ?
I assume you are talking about the NAS Security_Mode_Command message, described in TS 33.401 section 7.2.4.4, and defined in TS 24.301 section 8.2.20.
From TS 24.301 section 8.2.20, we can see that Security_Mode_Command contains the information element "Selected NAS Security Algorithms", which is defined in section 9.9.3.23.
I think the answer to your question is, that you should check this field.
If it contains a valid value for an algorithm, then ciphering should be switched on using this algorithm. But if ciphering is already on, and it contains
0 0 0 EPS encryption algorithm EEA0 (null ciphering algorithm)
then no ciphering should be applied. Therefore, you could interpret that as "switch off ciphering".
But I also note that the same spec says in section 8.2.20 Security Mode Command, that
This message is sent by the network to the UE to establish NAS signalling security.
So, I'm not completely sure if it should be sent to switch ciphering off, as that's not specifically mentioned in the spec.
Are there any specifications in the Java Card API, RE or VM specs as to how the card must react to faulty ISO7816-4 APDUs (provided that such malformed APDUs are passed to the card at all)?
Are there different requirements for the APDU handling of applets?
If I were to send e.g. a (faulty) 3-byte long first interindustry APDU to the
card/applet - who should detect/report this error?
Who would detect/report a first interindustry APDU containing a bad LC
length field?
No, there is no generic specification that defines how to handle malformed APDU's.
In general you should always return a status word that is in a valid ISO 7816-3/4 range. Which one depends fully on the context. Generally you should try always to throw an ISOException with a logical status word on error conditions. You should try never to return a 6F00 status word, which is returned if the Applet.process() method exits with an exception other than ISOException. The most common (not all) ISO status words have been defined in the ISO7816 interface.
Unfortunately, ISO 7816-4 only provides some hints regarding which status words may be expected. On the other hand, unless the error is very specific (e.g. incorrect PIN), there is not too much a terminal can do if it receives a status word on a syntactically incorrect APDU (it is unlikely to fix an incorrect APDU command data field). Any specific status words should be defined by higher level protocols. ISO 7816-4 itself can only be used as a (rotten) foundation for other protocols. No clear rules for handling syntactic (wrong length) or semantic (wrong PIN) errors have been defined.
With regard to malformed APDU's: 3 byte APDU's won't be received by the Applet. Bytes with an incorrect Lc byte may be received. It would however be more logical if this would influence the transport layer in such a way that the transport layer either times out because it is expecting more data, or that spurious bytes are discarded. It cannot hurt to check and return a wrong length error, but please use the values of APDU.getIncomingLength() or APDU.setIncomingAndReceive() as final values for Ne if you decide to continue.