Posts Tagged ‘techie’

1. I have minions!

2. My minions are AWESOME!

3. While I am away from my minions, I wanna make sure that they are safe and happy.

Hence, I am preparing a super (duper) tiny project to alert me of movement around my minions (as I said, only I am allowed around my minions).

Parts

1. Motion detector (PIR sensor)

2. Wires (the sensor needs 3: ground, out, vcc)

3. Arduino board

4. I had Python on my mac-mac, but I also had to install pyserial, in order to communicate to the Arduino board, via the serial port. In my case, the Arduino board is reachable via /dev/cu.usbmodem1421, on other systems it’s probably different.

Picture

20150408_200557

A bit of explanation

Basically, the “plan” is to log something to Serial port from Arduino, everytime I detect movement around my Minions. If that happens, I log “Movement!” to the Serial port. Then, from Python, I monitor the serial port, and if I read “Movement!”, then I send an email to myself, using my Gmail account, alerting me that the safety of the Minions has been compromised 🙂

Code

1. Arduino code

int pirPin = 7;

int spamInterval = 60; // send email max every 1 min

long lastSend = -spamInterval * 1000l; // measured in milliseconds

void setup()
{
pinMode(pirPin, INPUT);
Serial.begin(9600);
}

void loop()
{
long now = millis();
if (digitalRead(pirPin) == HIGH)
{
if (now > (lastSend + spamInterval * 1000l))
{
Serial.println(“Movement!”);
lastSend = now;
}
else
{
Serial.println(“Let’s not spam”);
}
}
delay(500);
}

2. Python code

import time

import serial

import smtplib

import io

TO = ‘cristina.vintila@gmail.com’

GMAIL_USER = ‘cristina.vintila@gmail.com’

GMAIL_PASS = ‘no, you cannot get this one ;)’

SUBJECT = ‘Intrusion!!’

TEXT = ‘Watch the Minions! The Minions are not safe!’

ser = serial.Serial(‘/dev/cu.usbmodem1421’, 9600)

def send_email():

    print(“Sending Email”)

    smtpserver = smtplib.SMTP(“smtp.gmail.com”,587)

    smtpserver.ehlo()

    smtpserver.starttls()

    smtpserver.ehlo

    smtpserver.login(GMAIL_USER, GMAIL_PASS)

    header = ‘To:’ + TO + \n + ‘From: ‘ + GMAIL_USER

    header = header + \n + ‘Subject:’ + SUBJECT + \n

    print header

    msg = header + \n + TEXT + \n\n

    smtpserver.sendmail(GMAIL_USER, TO, msg)

    smtpserver.close()

while True:

    message = ser.readline()

print(message)

    if message[0] == ‘M’ :

        send_email()

    time.sleep(0.5)

#ser.close()

3. Output

rbh:Arduino cristina$ python safeMinions.py

Let’s not spam

Let’s not spam

Movement!

Sending Email

To:cristina.vintila@gmail.com

From: cristina.vintila@gmail.com

Subject:Intrusion!!

Let’s not spam

And I have the email 🙂

Happily, I am right next to the Minions, and I know they are safe

Arduino – making pretty sounds

Posted: April 8, 2015 in technical
Tags: , ,

Cristina is girlie and she likes PINK! Unfortunately, the LED part is the only one I couldn’t make work 😦 😦 hence no pink display for me.

The next best thing: we make pretty sounds!

Parts

1. Piezo (I have no proper speaker): well, I use it to make the (pretty) sounds

2. Light sensor + 1K Ohm resistor

I used this only in the beginning, as I wanted to make the piezo play sounds based on the light intensity. As I am not able to control the light intensity in my room in a good-enough way to make sounds, I decided to use the distance variation to play different tones (see 3).

3. Ultrasonic sensor: well, I use it to measure the distance from the sensor to my palm and based on this variation I scale the distance from CM to Hz and play the tones within a range of musical notes:

int tones[] = {261, 277, 294, 311, 330, 349, 370, 392, 415, 440, 450};
// mid C, C#, D, D#, E, F, F#, G, G#, A, higher

How did I end up with these values?

Well, I have not. That’s just how they are. The frequency of Mid C is 261.6 Hz, and the others as above. What I tried then to ensure is that I map the distances from the Ultrasonic reader to a range of frequencies which “make sense” (between 200 and 300 Hz). As I would just flip my hand around the sensor to no longer than 100 cm, I just decided to add 200 to the distance computed by the sensor, in order to create the pitch (I am sure there are much better ways to do this).

4. Wires (the Ultrasonic sensor needs 4 – as it has 4 PINs: VCC, Trigger, Echo, Ground)

5. Yeah, and the Arduino board and breadboard, otherwise: no magic

Picture

20150408_191513

Code

v0.1 (using the Light sensor)

int speakerPin = 12;
int photocellPin = 0;

int numTones = 11;
int tones[] = {261, 277, 294, 311, 330, 349, 370, 392, 415, 440, 450};
// mid C C# D D# E F F# G G# A others

void setup()
{
for (int i = 0; i < numTones; i++)
{
tone(speakerPin, tones[i]);
delay(500);
}
noTone(speakerPin);
}

void loop()
{
int reading = analogRead(photocellPin);
int pitch = 200 + reading / 4;
if (pitch <= 261)
{
tone(speakerPin, tones[0]);
}
else if (pitch > 261 && pitch <= 277)
{
tone(speakerPin, tones[1]);
}
else if (pitch > 277 && pitch <= 294)
{
tone(speakerPin, tones[2]);
}
else if (pitch > 294 && pitch <= 311)
{
tone(speakerPin, tones[3]);
}
else if (pitch > 311 && pitch <= 330)
{
tone(speakerPin, tones[4]);
}
else if (pitch > 330 && pitch <= 349)
{
tone(speakerPin, tones[5]);
}
else if (pitch > 349 && pitch <= 370)
{
tone(speakerPin, tones[6]);
}
else if (pitch > 370 && pitch <= 392)
{
tone(speakerPin, tones[7]);
}
else if (pitch > 392 && pitch <= 415)
{
tone(speakerPin, tones[8]);
}
else if (pitch > 415 && pitch <= 440)
{
tone(speakerPin, tones[9]);
}
else
{
tone(speakerPin, tones[10]);
}
}

v0.2 (using the Ultrasonic sensor)

int speakerPin = 12;
int trigger=7;
int echo=6;
long time=0;
long dist=0;

int numTones = 11;
int tones[] = {261, 277, 294, 311, 330, 349, 370, 392, 415, 440, 450};
// mid C C# D D# E F F# G G# A others

void setup()
{
Serial.begin(9600);
pinMode(trigger, OUTPUT);
pinMode(echo, INPUT);

for (int i = 0; i < numTones; i++)
{
tone(speakerPin, tones[i]);
delay(500);
}
noTone(speakerPin);
}

void loop()
{
digitalWrite(trigger, LOW);
delay(5);
digitalWrite(trigger, HIGH);
delay(10);
digitalWrite(trigger, LOW);
time = pulseIn(echo, HIGH);
dist = (time/2) / 29.1;

if ( dist >= 500 || dist <= 0)
{
Serial.println(“No measurement”);
}
else
{
Serial.println(dist);

int pitch = 200 + dist ;
if (pitch <= 261)
{
tone(speakerPin, tones[0]);
}
else if (pitch > 261 && pitch <= 277)
{
tone(speakerPin, tones[1]);
}
else if (pitch > 277 && pitch <= 294)
{
tone(speakerPin, tones[2]);
}
else if (pitch > 294 && pitch <= 311)
{
tone(speakerPin, tones[3]);
}
else if (pitch > 311 && pitch <= 330)
{
tone(speakerPin, tones[4]);
}
else if (pitch > 330 && pitch <= 349)
{
tone(speakerPin, tones[5]);
}
else if (pitch > 349 && pitch <= 370)
{
tone(speakerPin, tones[6]);
}
else if (pitch > 370 && pitch <= 392)
{
tone(speakerPin, tones[7]);
}
else if (pitch > 392 && pitch <= 415)
{
tone(speakerPin, tones[8]);
}
else if (pitch > 415 && pitch <= 440)
{
tone(speakerPin, tones[9]);
}
else
{
noTone(speakerPin);
}
} // end distance measurement
delay(1000);
}

Yes, I did use the Serial.println for debugging, printing is the best form of debug 🙂 🙂 🙂

So it seems that I am back on “blogging”. Long time no see, my friends 🙂 and thanks for all the messages I got in the meantime.

Most probably I won’t be able to keep up blogging as in the past (not enough time to do all the geeky stuff), but I will not abandon it anymore.

The past few days I’ve found out about the passing of a friend, one of the geekiest people I know, an elderly gentleman, who has spent most of his life in the search for knowledge (he was speaking 11 foreign languages), curiosities and geeky stuff (a BSD passionate and founder of the foundation behind EuroBSDCon). I was very sad to get the news from Gavin and Henning this week, posted via the OpenBSD lists.

RIP Paul!

So, given the fact that for the past few weeks I can only sleep till 2AM every night, with occasional nights when I can fall asleep somewhere close to the morning, I have decided to spend this time on something useful, rather than with thinking and worrying about purpose of life and ponies and butterflies. First thing at hand: my new Arduino kit.

First time playing with this toy, I’ve went through the Startup Guide, and made the lights blink, the buzzer go off etc. The ones I am going to use later on though are the following:

1. Distance detector

https://drive.google.com/file/d/0By4rOXj_UNlEdVZMVHBjb2tJOGs/view?usp=sharing

2. Light sensor

https://drive.google.com/file/d/0By4rOXj_UNlEVnpaaXJQRUQweVE/view?usp=sharing

3. Movement detector

https://drive.google.com/file/d/0By4rOXj_UNlETzN6aUhkcGhNZzQ/view?usp=sharing

4. Temperature sensor

https://drive.google.com/file/d/0By4rOXj_UNlEeUpaSHJiRTZOZ0k/view?usp=sharing

5. (for the future) Servo engine

https://drive.google.com/file/d/0By4rOXj_UNlET0FfMW90bkFRMUk/view?usp=sharing

Indeed, these are just playing around with the very basics, but at least now I get the logic of how this works, and the code itself looks a lot like C programming, with libraries you can include and work with (and have the Arduino board become unresponsive when the libraries folder has a different name than the .cpp file inside it).

https://drive.google.com/file/d/0By4rOXj_UNlEamhKOTluZllPVDA/view?usp=sharing

Aaah, the sweet smell of burned plastic when you placed the Temperature sensor backwards on the breadboard!! 😛

TemperatureSensor

Mwell…my dear dear journal, today I had to learn about Mobility over SAE. As we very well know, our naughty user (User Equipment) does not just stay in one single cell, but rather moves around between different antennas. As per TS 23.401 (I have studied the June edition), there are several “cases” of mobility, or handover, as the 3GPP guys call them.

What is to know about how these “cases” are delimited:

1. whether the UE only moves from one eNodeB to another (the rest of the EPS is the same) or other components (like MME and/or SGW) are also changing => X2-handover and S1-handover

2. whether or not the eNodeBs are connected each-other (when they are connected, the interface is called X2) => this results in 2 separate cases: Direct Tunneling (we have X2) and Indirect Tunneling (we don’t have X2)

3. whether or not the MME changes (is relocated, as per the TS) => no MME relocation and MME relocation scenarios

4. whether or not the SGW changes (is relocated, as per the TS) => no SGW relocation and SGW relocation scenarios

5. in each of these cases, what happens to the user-plane traffic in terms of the path it takes; the uplink usually goes directly through the new components of handover, but the downlink data is forwarded back and forth around those elements – in the diagrams attached I have represented the user-plane in dotted lines – hope you’d like it 😛

6. the user-plane flow problem appears only in the time interval that the handover is not completed, otherwise it is the usual; this is why there is only a downlink user-plane traffic described

So—let’s do this by the book.

TS 23.401, section 5.5.1.1.2 – X2-based handover with NO SGW relocation and NO MME relocation (implicit direct tunneling)

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55112

TS 23.401, section 5.5.1.1.3 – X2-based handover with SGW relocation and NO MME relocation (implicit direct tunneling)

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> target eNB -(via LTE radio)> UE

55113

* no MME relocation for X2-based handover :d

TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Direct Tunneling

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PWG -(via S5/S8)> SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55122-dir

TS 23.401, section 5.5.1.2.2 – S1-based handover, NO SGW relocation and MME relocation + Indirect Tunneling

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> SGW -(via S1-U)> source eNB -(via S1-U)> SGW -(via S1-U)> target eNB -(via LTE radio)> UE

* this is the case when there are some downlink packets that have been forwarded from the SGW to the source eNB, BEFORE the handover is completed; this means that the source eNB (knowing there is a handover ongoing), resends/sends back these packets to the SGW they came from; the SGW, at this point, should be aware of the handover and buffer the packets until the handover is completed, then forward them via the appropriate S1-U to the target eNB

55122-indir

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and NO MME relocation + Indirect Tunneling

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE

55123-indir-no-mme

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Direct Tunneling

– UE moves from source eNB to target eNB, the X2 interface is present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via X2)> target eNB -(via LTE radio)> UE

55123-dir

TS 23.401, section 5.5.1.2.3 – S1-based handover, SGW relocation and MME relocation + Indirect Tunneling

55123-indir

– UE moves from source eNB to target eNB, the X2 interface is NOT present

– the downlink data flows this way: PGW -(via S5/S8)> source SGW -(via S1-U)> source eNB -(via S1-U)> source SGW -(via…to check this up)> target SGW -(via S1-U)> target eNB -(via LTE radio)> UE

 

The signaling required for these handovers are described in TS 23.401 as a flow and in TS 29.274 at the IE level.

I will try to describe each flow (or at least the most significant ones) in future articles. Enjoy :p

At first, I thought I was too noob to understand this stuff. I still consider myself a noob, but the way these TSs are written sometimes really gets on my nerves.

Let’s just consider the case of the S1-based handover with MME relocation and SGW relocation and Indirect Tunneling – meaning there is no X2 link between the source and target eNBs. All I can do for the moment is to look at the S11 interface, because this is the one I have the opportunity to study at this point.

So, the 2 TSs involved in this case, at least at the high  level are TS 23.401 – which describes the message flows between the SAE entities and TS 29.274 – which describes each message and its IEs.

The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:

55123-indir

In order to make this more human-readable, I have considered the following scenario:

mme2

where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doing X2 handover (with no MME relocation), then it moves from eNB 30.0.0.5 to eNB 30.0.0.8 (which don’t have an X2 link between them). As you can see from the picture, these 2 eNBs belong to 2 different MMEs and SGWs. This means that, when the UE moves from eNB5 (30.0.0.5) to eNB8(30.0.0.8), it will generate an S1 handover signaling between the source MME – MME1 (30.0.1.1), source SGW – SGW1 (30.0.2.1), target MME – MME4 (30.0.1.4) and target SGW – SGW2 (30.0.2.2). As there is no X2 link between eNB5 and eNB5, the downlink packets coming from the PGW while the UE is in the handover process with reach eNB5, then they will be “reflected” back to SG1, which will then forward them via an “indirect” tunnel to SGW2, which will forward them to the new eNB8, which is in charge of my UE.

The flow is like this (3GPP copy-pasted 🙂 )

ts1

1)  So, as this picture states, once the handover is decided, the source MME sends a Forward Relocation Request to the target MME. This message must at least contain the following mandatory IEs, as per TS 29.274:

– IMSI

– Sender’s F-TEID for Control Plane

– MME/SGSN UE EPS PDN Connections

– SGW S11/S4 IP Address and TEID for Control Plane

– MME/SGSN UE MM Context

2) Then the target MME sends a Create Session Request message to the target SGW, including (M == Mandatory):

– IMSI (M)

– RAT Type – here is E-UTRAN (M)

– Sender F-TEID for Control Plane – here it is the IP address of the source MME: 30.0.1.4 + it’s TEID/GRE Key (this “key” is actually a hexadecimal number on 2 bytes) (M)

– APN Name (M)

– Maximum APN Restriction (M)

– LBI – Linked EPS Bearer ID – indicates the default bearer of the connection – the ID of the default bearer, usually this has value 5 (C)

– PGW S5/S8 Address for Control Plane or PMIP – this is the IP address of the PGW: 20.0.0.1 (C)

3) the target SGW replies to the target MME with a Create Session Response message, containing:

– Cause (M)

– Sender F-TEID for Control Plane – this is the IP address of the target SGW: 30.0.2.2 (C)

– APN Restriction (M)

– Bearer Contexts created (M) – this means that all the bearers that have the OK to be created for the UE in question are going to be present here, in a separate group IE; the IEs within a Bearer Context have the following:

— EBI – EPS Bearer ID (M)

— Cause (M)

— S1-U SGW F-TEID – the IP address of the SGW used for user-plane and a TEID/GRE identifier on 2 bytes – this is usually the same identifier used for the initial traffic of this user, _before_ the handover, let’s just call it Key-A – which is the uplink identifier for the user (C)

— Bearer Level QoS – the new QoS parameters, if they have been changed (C)

** Let’s stop for a second a recap. What do I have at this point? I have an UE (UE-1 in the picture) with an IP address (let’s say: 40.0.0.91). It is attached to the eNB 30.0.0.5, having a default bearer in place with the MME 30.0.1.1 (source) and the SGW 30.0.2.1 (source). This default bearer has an uplink identifier TEID, called as above Key-A, which also has a downlink identifier TEID, called Key-1. Let’s say that what travels in uplink has a key made out of letters, and what travels in downlink has keys made out of numbers 🙂

Ooook, what’s next. Well, as my UE moves to eNB 30.0.0.8, AND there is no X2 link between eNB5 and eNB8, target MME creates an indirect tunnel for the packets. Once the UE has moved to eNB8, the uplink flows directly from this new eNB, to the new SGW and so on. So, the indirect path is for the downlink packets, more precisely, for THOSE downlink packets that have already been routed by the source SGW to the source eNB (eNB5). eNB5 cannot contact eNB8 directly, so it re-routes these packets back to the source SGW, which will also re-route them via this indirect tunnel to the target SGW – which has direct S1-U connectivity to the target eNB to deliver the packets to my dear UE 🙂

How does EPC do that?

4) Target MME (30.0.1.4) sends a Create Indirect Data Forwarding Tunnel Request message to the Target SGW (30.0.2.2), containing all the grouped IEs Bearer Contexts that are to be forwarded this way, this grouped IE being the only Mandatory IE in this message. This Bearer Context IE contains:

— EBI – EPS Bearer ID (M)

— S1-U eNodeB F-TEID for data forwarding – this is the IP address of the target eNB (30.0.0.8) and its associated TEID/GRE key, let’s call it Key -2. This key instructs the target SGW about the destination of the packets for my UE (C)

5) then the Target SGW (30.0.2.2) responds to this message with a Create Indirect Data Forwarding Tunnel Response message. This message has 2 Mandatory IEs: the Cause and the Bearer Contexts grouped IE. This Bearer Context IE has:

— EBI (M)

— Cause (M)

— S1-U SGW F-TEID for data forwarding – this is the IP address of the target SGW and its TEID/GRE identifier – Key-B

6) After this, the target MME sends a Forward Relocation Response message to the source MME, instructing it about the bearers that have been accepted for creation on this indirect path

7) Now, the source MME (30.0.1.1) sends a Create Indirect Data Forwarding Tunnel Request to the source SGW (30.0.2.1), with elements similar to the corresponding message above, except that in this case, the Bearer Context has the TEID/GRE identifiers of the target SGW, contained in the Create Indirect Data Forwarding Tunnel Response from above – Key-B – when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets

8) The source SGW responds with a Create Indirect Data Forwarding Tunnel Response message, same as above, but the TEID/GRE ID is the one of the IP address of the source SGW. This ID shall be used for uplink data on the indirect tunnel from the source eNB to the source SGW. Let’s call this ID Key-3.

*** At this point, we have an indirect tunnel created between the following entities:

source eNB (30.0.0.5) -> source SGW (30.0.2.1) : TEID Key-3

source SGW (30.0.2.1) -> target SGW (30.0.2.2) : TEID  Key-B

target SGW (30.0.2.2) -> target eNB (30.0.0.8) : TEID Key-2

At this point, the user traffic is like this:

traffic

1: packets already forwarded by the source SGW to the source eNB are “reflected” by this eNB – use the downlink GRE ID established initially, Key-1

2: the reflected packets from source eNB back to source SGW use the GRE negotiated via the messages above: Key-3

3: packets then travel on the tunnel from source to target SGW, via the TEID/GRE ID: Key-B

4: then the target SGW finally forwards the packets down to the target eNB via GRE ID: Key-2

*** During all this complicated process, the uplink is already using the target eNB as source for the encapsulating tunnel

So, what happens afterwards?

9) the target MME sends a Modify Bearer Request message to the target SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and the target SGW replies with a Modify Bearer Response message in order to acknowledge (or state a cause for rejecting) this

10) the source MME deletes its session from its (source) SGW, using a Delete Session Request /  Delete Session Response pair of messages, carefully indicating the SGW that this is only a “local detach” of the UE, not a complete detach, meaning that the UE just moved and the local information about it is no longer valid, NOT that the UE disappeared from the network and the resources are to be deleted !

11) 12) both pairs of source and target MME/SGW now delete the indirect tunnel by exchanging the Delete Indirect Data Forwarding Tunnel Request / Delete Indirect Data Forwarding Tunnel Response messages.

And everybody is happy.

EXCEPT Me, because there are a lot of misleading and confusing “explanations” in the specs regarding this type of scenarios, like for instance:

a) one spec (TS 23.401) states that the delete session procedure should have Cause and LBI IEs in the Create Session Request message, while TS 29.274 defines these 2 IEs as Conditional, and, as per the condition in place, none of them should appear in this message when the source MME disconnects from the source SGW. Instead, the SGW should look at the Indication Flags in this request: if the Operation Indication is set, then this is a full detach, if the Scope Indication is set, this is a local detach.

b) look at the above flags: shouldn’t it be better to have just 1 flag, and, if it is set, we have a full detach, otherwise we have a local detach?

c) what happens in the S1 handover with no SGW relocation (whether or not the MME is relocated) and Indirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?

and more to come

AXFR vs. IXFR

Posted: May 4, 2014 in technical
Tags: ,

https://www.sans.org/reading-room/whitepapers/dns/securing-dns-zone-transfer-868

Check Point R77

Posted: September 20, 2013 in technical
Tags: , , ,

Yes, 77, nice number – I said.

Besides that, though:

New Threat Emulation Software Blade
New Check Point Compliance Blade
HyperSPECT Technology
Gaia Operating System Enhancements
Enhanced Gaia Software Updates
Enhanced Identity Awareness
Enhanced Endpoint Security
Note: Endpoint Security E80.50 clients will be available only by end of September 2013.
– Full Disk Encryption
– Endpoint Security Client – General
– Anti-Malware
– Firewall
– Media Encryption & Port Protection
Security Gateway Virtual Edition
Enhanced VSX
Enhanced SAM Card Support
Mobile Access

full list at the CKP UserCenter

CheckPoint_R77

http://wipkip.nikhef.nl/events/OHM/video/d4-t2-04-20130103-1400-sim_card_exploitation-karsten-nohl.m4v

This comes a bit (ok, a lot) late, but I can never keep up with my emails.

So: August starts in force, by posting out 2 nice specifications for public review. One and only shot to get a look at a GP draft, without having to pay for the bloody stuff. No pun intended on GP, actually they do publish quite a bit of specs freely for research on their website.

So, the lucky winers are:

GlobalPlatform Device Technology TEE TA Debug Specification v0.41

and

GlobalPlatform Card Technology Card Specification – ISO Framework v0.9.0.18

For those of you interested in the mobile phones part of the game, I would go for the former link. I am personally more interested in the SIM/SmartCards. Nevertheless, understanding the debugging framework proposed by GP might be useful for the SmartCard part also. Afterall, they all fit together nicely and a lot of the security (and security _gaps_) in SmartCard technology are not necessarily of a problem of the SmartCard itself, but rather of how it is handled – e.g. how the Android/mobile OS communicates with it.

 

I have just had a series of talks the past weeks with a good friend of mine. He is a Security Architect for a large company up north. I’m curious about what he is doing there, so initially I was thinking of organising our discussions as some form of an interview. Later on, my proverbial laziness got the best of me, so I downgrade our nice chat to a short blog post (this one).

Bottom line: I’ve asked him what it means to be a Security Architect. It went somewhere along these lines:

What are you doing there? Is it cool? Is it nice? Do you do cool stuff? Cristina being a bit of a chipmunk at this point

You won’t find it that cool, most probably. I don’t get to dig into the GTPv2 as you do.

Absolutely unsatisfactory – I say. Nevertheless, our discussion digressed into an interesting side-area: security frameworks and how to do network architectures security assessments. I asked for a framework to do these assessment.

Ok I will recommend something – but I don’t usually stick to frameworks, as it depends on the assignment and other stuff more to me. Like experience. So I go by from my head – yueah I know it sounds bad, but it works for me, as long as I remember to include all the areas.

Again, completely unsatisfactory – I say. Still, continuing the discussion, I realise the guy is right: it _actually IS_ about experience. Whatever “framework” is just a nice area checklist to help you with not missing out on stuff. This guy has too much experience to use any frameworks at the moment, but I need something to start learning this stuff. I did find something, and my friend corroborated my findings. Fortunately, his examples and details from his experience nicely matched the framework that I also liked for my research: ITU-T X.805.

(more…)