I build open cryptoki library from source and try to initialize the software token.
but when running pkcsconf -I -c 3 for initializing the token, I get the following Error message:
Enter the SO PIN:
Enter a unique token label: poef
Error initializing token: 0xA4 (CKR_PIN_LOCKED)
The token Info looks like this:
$ pkcsconf -t
Token #3 Info:
Label: IBM OS PKCS#11
Manufacturer: IBM Corp.
Model: IBM SoftTok
Serial Number: 123
Flags: 0xD80045 (RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|USER_PIN_TO_BE_CHANGED|SO_PIN_COUNT_LOW|SO_PIN_LOCKED|SO_PIN_TO_BE_CHANGED)
Sessions: 0/18446744073709551614
R/W Sessions: 18446744073709551615/18446744073709551614
PIN Length: 4-8
Public Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Private Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Hardware Version: 1.0
Firmware Version: 1.0
Time: 08:07:03
So as I understand I should reset the Software Token, to get a default SO PIN and could initialize the token, to use it. But I cannot find anything about that in the official docs.
To reset everything, you have to delete the content of /var/opencryptoki/swtok
Have you seen this page https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxce/lxce_initializing_ep11token.html
I have no familiarity with this specific SW P11 implementation but the command sequence here seems to make sense.
The default pin is 12345678, you would want to change that, initialize the user pin, change that. Theory being that in that sequence you wont be locked.
Related
i have got modem with double sim slot to insert two different sim cards.
mmcli output:
-----------------------------------
3GPP EPS | ue mode of operation: csps-2
| initial bearer path: /org/freedesktop/ModemManager1/Bearer/2
| initial bearer ip type: ipv4v6
-----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/3
| sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/2
| slot 2: /org/freedesktop/ModemManager1/SIM/3 (active)
-----------------------------------
Bearer | paths: /org/freedesktop/ModemManager1/Bearer/3
Is there a possibility to get two activated wwan's from this sim cards? I can switch between them but i want to try to get two of them at once.
Thanks a lot for any suggestions.
It may be unworkable. Producer not provide dual sim support for model of modem which i have.
Additional information in this link Quectel Specification. There are no information about 'dual sim' unlike these SCx modems
[Question posted by a user on YugabyteDB Community Slack]
I'm just testing yugabyte under some negative tests and I'm facing a kind of issue. I'm running a 3 node cluster (master and tserver running on same node) When I stop one node and start it up again, T-server is not booting up under this log
F20220506 06:50:49 ../../src/yb/tserver/tablet_server_main.cc:220] Invalid argument (yb/util/universe_key_manager.cc:73): Could not init Tablet Manager: Failed to open tablet metadata for tablet: eb1e5457022f42c084148ca8fa4ba5c6: Failed to load tablet metadata for tablet id eb1e5457022f42c084148ca8fa4ba5c6: Co
uld not load Raft group metadata from /data/yugabyte/data/yb-data/tserver/tablet-meta/eb1e5457022f42c084148ca8fa4ba5c6: Key with version number c7b91fad-dd60-404f-8846-cab568e52468 does not exist.
# 0x7fcdace5ee4c yb::LogFatalHandlerSink::send()
# 0x7fcdaa5e28ee google::LogMessage::SendToLog()
# 0x7fcdaa5dfa7a google::LogMessage::Flush()
# 0x7fcdaa5e3169 google::LogMessageFatal::~LogMessageFatal()
# 0x4124ea yb::tserver::(anonymous namespace)::TabletServerMain()
# 0x7fcda6811825 __libc_start_main
# 0x410f99 _start
# (nil) (unknown)
The only way to start it up is remove the old data.
My steps were:
1.- Cluster up with 3 server
2.- Create a taable with 3 partition on different tablet id confirmed via UI)
3.- Insert 3 different row to diff partition
4.- Select * working fine
5.- Shut down one Table server
6.- Select * working fine
7.- Starting up the table server (error)
We are running using config file:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/./yb-tserver --flagfile /data/yugabyte/etc/tserver.conf
and config:
--tserver_master_addrs=ip1:7100,ip2:7100,ip3:7100
--rpc_bind_addresses=fqdn
--server_broadcast_addresses=ip1
--enable_ysql
--pgsql_proxy_bind_address=ip1:5433
--cql_proxy_bind_address=ip1:9042
--fs_data_dirs=/data/yugabyte/data
--placement_cloud=cloud
--placement_region=reg
--placement_zone=zone
--use_client_to_server_encryption=true
--certs_for_client_dir=/data/yugabyte/ssl
--certs_dir=/data/yugabyte/ssl
--use_node_to_node_encryption=true
--ysql_enable_auth=true
--log_dir=/data/yugabyte/logs
--ssl_protocols=tls12,tls13
--ysql_pg_conf=pgaudit.log='DDL',pgaudit.log_level=notice,pgaudit.log_client=ON,log_min_messages=notice,log_line_prefix='\%m \%r \%u \%d [\%p]'
Looks like the key is not in memory:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses $master get_universe_config
{"version":2,"replicationInfo":{"liveReplicas":{"numReplicas":3,"placementBlocks":[{"cloudInfo":{"placementCloud":"cloud","placementRegion":"region","placementZone":"zone"},"minNumReplicas":1}]}},"clusterUuid":"dccea8cb-9790-48ba-8a05-6218a8e875a4","encryptionInfo":{"encryptionEnabled":true,"universeKeyRegistryEncoded":"sZTzNciYu6b1KxZonpJx6v7CDDvexiv1jh/HIEAOkpV4YRrIZbIK9jtajdEMmVEUy706+dmz8bmnZvy6/n33u+qS7fzRSOTPOlpxYI6+k1lSM6bu2DRTTffhZtaiKN15gy8a3ifaZV7xJ9QJ3z9SvFYzb96+KDWw","keyPath":"/data/yugabyte/rest/universe_key","latestVersionId":"c7b91fad-dd60-404f-8846-cab568e52468","keyInMemory":false}}
KeyInMemory: False
We are using encryption at rest but the the file with the key should be there.
Am I doing something wrong?
usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses fqdn:7100 all_masters_have_universe_key_in_memory 7e13c99e-5278-4abd-ab78-79f70d6c2679
Error running all_masters_have_universe_key_in_memory: Operation failed. Try again. (yb/tools/yb-admin_client_ent.cc:1027): Unable to check whether master has universe key in memory.: Node fqdn:7100 does not have universe key in memory
The above error seems to indicate the tserver is looking for a key - “c7b91fad-dd60-404f-8846-cab568e52468” in order to open the file, but can’t find it.
Realizing that there’s an actual key file on the masters. That’s been deprecated for using more secure in-memory keys. I just did a little digging through the code, and sure enough, we don’t actually support sending on-disk keys to tablet servers on restart.
The command you have to run is this one:
yb-admin -master_addresses <master-addresses> add_universe_keys_to_all_masters <key_id> <key_path>
and then right after that it should work:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses $master all_masters_have_universe_key_in_memory 1
Node fqdn1:7100 has universe key in memory: 1
Node fqdn2:7100 has universe key in memory: 1
Node fqdn3:7100 has universe key in memory: 1
I received this error:
This is an automatically generated mail message from mdadm
running on host.xx.xx
A Fail event had been detected on md device /dev/md2.
It could be related to component device /dev/sda2.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid1]
md2 : active raid1 sdb2[1] sda2[2](F)
523200 blocks [2/1] [_U]
md4 : active raid1 sdb4[1]
1901261760 blocks [2/1] [_U]
bitmap: 5/15 pages [20KB], 65536KB chunk
md3 : active raid1 sdb3[1]
51198912 blocks [2/1] [_U]
unused devices:
Then I received this other email:
Subject: FailedOpenDevice
Device: /dev/sda [SAT], unable to open device
How can I know if I have a problem in one of the 2 disks I have?
How can I know if I have a problem in one of the 2 disks I have?
FailedOpenDevice Device: /dev/sda [SAT], unable to open device
You have a problem with your /dev/sda. You see sda2[2](F) in your mdstat, that (F) means that that disc (/dev/sda2) is faulty. See your dmesg for further errors.
I'm trying to install an applet on a SIM card wich supports java card V3.0.4. When I try to establish a secure channel to load the applet, the card returns an error:
mode_211
enable_trace
establish_context
card_connect
select -AID A000000151000000
Command --> 00A4040008A000000151000000
Wrapped command --> 00A4040008A000000151000000
Response <-- 6F108408A000000151000000A5049F6501FF9000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 79AA24D80FF0056101F1D9AB6DCAF0E6
-enc_key 79AA24D80FF0056101F1D9AB6DCAF0E6
Command --> 80CA006600
Wrapped command --> 80CA006600
Response <-- 664A734806072A864886FC6B01600B06092A864886FC6B020202630906072A86488
6FC6B03640B06092A864886FC6B048000640B06092A864886FC6B040255640B06092A864886FC6B0
481079000
Command --> 8050000008F05E65BF5254BC9F00
Wrapped command --> 8050000008F05E65BF5254BC9F00
Response <-- 00005147A5190C5352322002001C1F47B6C76BABFD305EBBC2CD1BB39000
mutual_authentication() returns 0x8030F00A (The Secure Channel Protocol passed and reported do not match.)
I'm using GPShell-1.4.4. I guess the problem is using wrong key set! Am I true or there is something else I cannot guess what?!
Thanks for your response,
(I am partly reusing an answer I wrote for your previous question which you suddenly deleted)
Error code GP211_ERROR_INCONSISTENT_SCP means that GPShell's intended SCP version mismatches with the real SCP version given by the card (see here).
Check the 12th byte of card response to INITIALIZE UPDATE -- Secure Channel Protocol identifier (see e.g. GP Card Specification 2.3, section E5.1.6) and use parameter -scp.
Alternatively you might want to use GlobalPlatformPro as GPShell is quite outdated...
Beware that you can block your card by issuing multiple INITIALIZE UPDATE commands without successful authentication!
As your current question contains the complete log it is possible to parse the Card Data tag giving (according to GP 2.2.1):
66 Card Data
73 Card Recognition Data / Discretionary Data Objects
06 OID
2A864886FC6B01 {globalPlatform 1} // Card Recognition Data
60 Application Tag 0
06 OID
2A864886FC6B020202 {globalPlatform 2 2 2} // GP 2.2 Card
63 Application Tag 3
06 OID
2A864886FC6B03 {globalPlatform 3} // Card Identification Scheme
64 Application Tag 4
06 OID
2A864886FC6B048000 {globalPlatform 4 128 0x00} // SCP80 i=0x00
64 Application Tag 4
06 OID
2A864886FC6B040255 {globalPlatform 4 2 0x55} // SCP02 i=0x55
64 Application Tag 4
06 OID
2A864886FC6B048107 {globalPlatform 4 129 0x07} // SCP81 i=0x07
So you might want to use -scp 2 -scpimpl 0x55 or -scp 2 -scpimpl 85 (which happens to be the same).
Or use GlobalPlatformPro.
Alternatively -scpimpl 0x15 should work as well as the Well-known pseudo-random algorithm
(card challenge) bit in 'i' should not matter...
Good luck!
I would like to detect if a botton is pushed on my SensorTag using the gatttool, but I'm not able to do that.
In http://processors.wiki.ti.com/index.php/SensorTag_User_Guide TI reports that in order to read the pressed buttons, you should:
1) Enable test mode by writing the value 0x80 to the AA62 (CONFIGURATION) attribute.
I did that with the command:
[CON][BC:6A:29:AE:CD:E5][LE]> char-write-req 0x67 80
[CON][BC:6A:29:AE:CD:E5][LE]> Characteristic value was written successfully
Now I should be in test mode, and:
2) Enable Simple keys notification
Looking at the http://processors.wiki.ti.com/index.php/File:BLE_SensorTag_GATT_Server.pdf
and at the bluepy lib it seems I've to write 0100 in 0x60 for doing that. But
[CON][BC:6A:29:AE:CD:E5][LE]> char-write-req 0x60 0100
[CON][BC:6A:29:AE:CD:E5][LE]> Characteristic Write Request failed: Attribute can't be written
I observed that 0x61 is writtable and accept the value 0100, but I'm still not able to
detect if a key is pressed.
Any suggestion?
That PDF document may be out of date... I just tried using gatttool on my SensorTag and got button notifications with the following command: char-write-req 0x6c 0100
I'd stick with just the TI wiki for the SensorTag as it's probably more likely to be kept up-to-date. The wiki says you only need to do that "test mode" step if you want to get notifications when the side button is pressed (because normally it just activates the advertising).
Also, you probably have to figure out what handle to use on your specific device as every firmware will cause the handles to move around. What shouldn't change between firmwares is the UUID. Try the primary and characteristics commands in gatttool to get the details of the services on the device.
My primary showed this:
attr handle: 0x005e, end grp handle: 0x0068 uuid: f000aa50-0451-4000-b000-000000000000
attr handle: 0x0069, end grp handle: 0x006d uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
attr handle: 0x006e, end grp handle: 0x0074 uuid: f000aa60-0451-4000-b000-000000000000
ffe0 is the UUID of the simple key service (though the wiki says it's f000ffe0, it's not on mine). So, all the handles you want to look at are from 0x69 to 0x6d
char-read-uuid 0x2902 0x69 0x6d will show all CCC (Client Characteristic Configuration) in that range:
handle: 0x006c value: 01 00
Setting that handle to 0100 will turn on notifications for that service.